Other Parts Discussed in Thread: MSP430FR5969
Tool/software: Code Composer Studio
In the referenced thread Steve Wenner was having an issue whereby the act of using the CCS memory browser to inspect information FRAM was causing the debugged program to fail.
While I don't have the same program and MSP430 FRAM device as Steve, with the attached example I was able to get CCS 10.1.1.00004 to cause the debugged program to fail when the memory browser is used.
Steps are:
1. Download the attached program to a MSP-EXP430FR5969. This is a simple program which has:
a. Timer B0 interrupt overflow toggling the green LED on P1.0
b. Red LED on P4.6 turned on at initialisation, and turned off when S2 pressed, via an interrupt. This can be used to detect an unexpected reset.
2. Set the program running. The red LED will be on and the green LED toggling slowly.
3. At the point both LEDs are on pause the program.
4. Open the memory browser and set the starting address to 0x01800 (the start of information memory). Both LEDs remain on.
5. In the memory browser use the cursor to move up, so the starting address changes from 0x01800 to say 0x017E8. At the point the memory browser starting address is changed both LEDs turn off, even though the CCS debugger indicates the program is still suspended.
6. Resume the program, but both LEDs remain off meaning the program has failed.
What I realised is that in MSP430 FRAM devices the BSL is in ROM, with most of the BSL addresses are protected against prevents erroneous BSL execution. E.g. in a MSP430FR5969 the ROM BSL is at addresses 0x1000 to 0x17FF, with only 0x1000 to 0x100F accessible outside of the BSL. When a test program was created for a MSP430FR5969 to probe the BSL ROM addresses, when the running program attempted to access addresses 0x1010 to 0x17FF a Security Violation (PUC) was generated which reset the device.
As of CCS 10.1.1.00004 there are no GEL files supplied for MSP430 devices, and therefore the CSS debugger thinks the entire address range of the MSP430 is accessible. What I think is happening is that if the CCS debugger attempts to access any of the protected BSL addresses then the device gets partial reset in some way.
In the attached project there is a msp430fr5969.gel file with the following contents:
StartUp()
{
GEL_MapReset();
GEL_MapOff();
/* Default the entire address space to read/write, to match the behaviour without a GEL file */
//@todo GEL_MapAdd seems to think a MSPX has only 16 address bits
GEL_MapAdd (0, 0, 0x10000, 1, 1);
/* Make the area of the BSL ROM which generates a Security Violation PUC as not accessible */
GEL_MapAdd (0x1010, 0, 0x7F0, 0, 0);
GEL_MapOn();
}
If the the target configuration file is modified to use the above GEL file then the CCS debugger is told that the protected BSL ROM addresses can't be accessed:
And if the CCS memory browser is used to attempt to access any protected ROM BSL address in the range 0x1010 to 0x17FF then get "----" displayed due to "Memory map prevented reading" and the debugged program no longer fails.
Should CCS supply default GEL files for MSP430 FRAM devices which have the protected BSL ROM addresses marked as inaccessible to prevent failures if the debugger attempts to access the addresses?
Also, the GEL_MapAddStr() and GEL_MapAdd() functions don't seem to allow specifying any addresses >= 64KB for the MSP430FR5969 with a MSPXv2 CPU, resulting in an "MSP430: Error adding memory map range: End address is beyond target memory length" error. I haven't determined how GEL determines the target memory length. For MSP CPUs the address space is 16 bits, and for MSPX and MSPXv2 CPUs is 20 bits.
MSP430™ FRAM Devices Bootloader (BSL) explains that for FR26xx, FR25xx, FR24xx, and FR23xx devices there is an upper 1KB of BSL ROM at 0xFFC00 to 0xFFFFF, and therefore can't see how the GEL memory map could be set to mark addresses 0xFFC00 to 0xFFFFF as inaccessible.
