This fixes a problem in the Nios II port where the debugger will cause the system to become unresponsive. GDB will try to be intelligent and retrieve the values of global variables (pxTopOfStack) when debugging if you have the disassembly, variable, or memory views open. This is only an issue if you:
Have the peripheral bridge enabled
Whatever address pxTopOfStack is initialized to points to an invalid/unused region in your memory map
You're debugging with one of the 3 views open (see above) or if you set a breakpoint
This bug generally manifests itself by getting "Cannot access memory at address 0xXXXXXXXX" GDB errors, being unable to set more than one breakpoint and/or the inability to single-step. By initializing pxTopOfStack to a known valid address, this problem is resolved.
You will also encounter this same problem if you have any uninitialized pointers in the scope of whatever function you're debugging. Initializing them to null/0x00000000 is safe with the nasty caveat of needing a device mapped to that address. This is generally the JTAG UART (0x00000000-0x0000000F). If you don't want a project-specific definition for null, an alternative could be moving SDRAM or OCM to start at that address.
I imagine the chances of someone else encountering this bug are pretty slim but I'm hoping that this fix will save at least one person the weeks of trying to track this problem down.
DipSwitch
commented
8 years ago
This fixes a problem in the Nios II port where the debugger will cause the system to become unresponsive. GDB will try to be intelligent and retrieve the values of global variables (pxTopOfStack) when debugging if you have the disassembly, variable, or memory views open. This is only an issue if you:
This bug generally manifests itself by getting "Cannot access memory at address 0xXXXXXXXX" GDB errors, being unable to set more than one breakpoint and/or the inability to single-step. By initializing pxTopOfStack to a known valid address, this problem is resolved.
You will also encounter this same problem if you have any uninitialized pointers in the scope of whatever function you're debugging. Initializing them to null/0x00000000 is safe with the nasty caveat of needing a device mapped to that address. This is generally the JTAG UART (0x00000000-0x0000000F). If you don't want a project-specific definition for null, an alternative could be moving SDRAM or OCM to start at that address.
I imagine the chances of someone else encountering this bug are pretty slim but I'm hoping that this fix will save at least one person the weeks of trying to track this problem down.