This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/MSP-EXP430FR5969: If the CCS debugger accesses an area of the ROM BSL in a MSP430 FRAM device which is protected, the debugged program fails

Part Number: MSP-EXP430FR5969
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 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 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:


    /* 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);

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.

  • Hi Chester

    Yes, I can reproduce your phenomenon and seems the resume is not work. But when re-power the device it works well. So the code have been download successfully. I will discuss it with CCS team to see if they have known the resume not work issue.

    Best regards


  • Gary Gao said:
    Yes, I can reproduce your phenomenon and seems the resume is not work.

    Looking at what happens with the resume failure, when the GEL file isn't used:

    1. Pause the program. Display the Memory Browser starting at address 0x01800 and display the Timer0_B7 registers:

    The program users TimerB, and so the non-zero register values are expected.

    2. Change the first address displayed in the Memory Browser to 0x017E8 by moving the cursor up in the view. Refreshing the register view shows the Timer0_B7 registers have been zeroed:

    In this state the program can no longer be resumed. I haven't fully understood what happens to the device, but the act of the CCS debugger accessing any of the BSL ROM protected addresses from 0x01010 .. 0x017FF appears to corrupt the state of the device. E.g. zeros some peripheral registers.

    Whereas when using the msp430fr5969.gel file which was created to prevent the debugger from accessing the BSL ROM protected addresses from 0x01010 .. 0x017FF then no longer causes a failure if the memory browser starts at address 0x017E8, in that the Timer0_B7 registers retain their state and the program can be resumed:

  • Hi Chester

    You are right add a GEL file to limit the access for the area that be protected can avoid this issue. Due to this just happen in MSP430FR5XX6XX devices that have secure the BSL area. I think that will not affect normal debug process with this issue right? Thanks to point it to us.

    Best regards


**Attention** This is a public forum