Global Variable Structure Woes

I have a couple of structures that I've created (see below).

typedef struct {
union {
struct {
unsigned u1_FlashingLED :1; // Boolean for whether LED is Flashing
unsigned u3_LEDColourIndex :3; //3 bits for LED Colour
unsigned u4_AlarmNotificationIconIndex :4; //4 bits for alarm notification icon index
uint8_t u8_IndicationByte;

typedef struct {
INDICATIONSTRUCT IS_LEDAlarm; //LED Colour/flashing and alarm icon index structure
uint16_t u16_ConditionIndex; //Condition Index
uint8_t u8_TimerIndex; //Timer Index
struct NotificationList * NL_Previous; //previoius item in linked list
struct NotificationList * NL_Next; //next item in linked list

I've created a global variable as a single NotificationList. I have initialized the values of the structure and verified that they are correct using a watch in the expressions window.

I allow my program to run, and then set a breakpoint that gets triggered 1 second later. When the breakpoint is triggered, the values in my indication structure have changed, but not by me. All the program is doing at this point is initializing a variable. The variable is read elsewhere in the program, but it is not written to except for the initialization since I'm trying to figure out what's going on. I'm coming up empty. Anybody have any thoughts?

I suspect I've either done something wrong in the creation of the structure or there's something going on that I don't understand.

I'm running E2Studio and SSP 1.3.3 on a custom S5D9 board.

  • Hi,

    How is the structure being created? Is it as a global variable? If it is a local then it will not retain contents unless it is declared as static or in a thread context. If it is being created on a thread stack is the stack size large enough?


  • In reply to Ian:


    Re-reading your post I see you are declaring the structure instance as global. When globals get corrupted one of the first places to consider is whether they are being overwritten by a thread stack. If you place a breakpoint on the stack monitor exception this will trigger is this is the issue.



    Find the following towards the bottom of the file:

    if (1 == R_ICU->NMISR_b.SPEST)
    /** MPU Stack Error interrupt is requested. */

    /** Clear MPU Stack error flag. */

    Place a breakpoint on the last line (R_ICU->NMICLR_b.SPECLR = 1U;).

    If you hit this breakpoint then the stack has been written outside of the stack space.


  • In reply to Ian:

    So I've got good/confusing news. I moved the location where the variable was being initialized. I had initialized it in a function that gets called when the GX_EVENT_SHOW event occurs, but instead I moved the initialization of the structure to the code of the graphics thread. Once I did this, everything works as expected. I have no idea why moving the initialization fixes everything though.


    I played around a bit more with the code, and after commenting out some code of the graphics thread, I'm right back where I started. The code I removed was writing to the QSPI and involved some delays to allow the writes to complete. This code that was removed took place before the initialization of the structure. With that code out, I'm right back where the variable is being overwritten somehow. It appears to be time based somehow?

    I tried placing the breakpoint in the NMI to see if anything was happening there, but it never entered that function.

  • In reply to Tim:


    It sounds like a timing or ordering of initialisation problem. Perhaps having the QSPI code in place is resulting in that thread suspending more often allowing another thread to run?

    It is possible to set a data access breakpoint which would allow you to see where the variable is being written. As far as I know this is not possible from within e2studio but instead it has to be configured in the J-Link Control Panel.

    With the debugger connected and code downloaded right click in the Windows notification area (next to the clock) and find the green J-Link icon. Click it an select open and then the Breakpoints tab. There you can set a data access breakpoint. Hopefully this may help you work out where the undesirable write to the variable is occurring.