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 10.2 + J-Link on Ubuntu 18-04 clears SRAM on connect. Reads first 64 kB as all zeroes

Other Parts Discussed in Thread: TMS570LC4357, SEGGER

Out board has an TMS570LC4357, 4 MB external SRAM, 16 MB SPI Flash, 8 MB CFI flash

I am trying to debug an application developed on Ubuntu 18.04, compiled by gcc.

I am planning to execute the application in external SRAM. CCS apparently cannot download the ELF file to external Flash/SRAM.

I therefore create a raw binary using objcopy which I download using my bootloader/Y-modem to the external SRAM.
I program an external SPI flash with the binary using the bootloader, and load it into the correct location.
During this period, the Parameter Overlay Module is enabled, and redirects the first 64 kB to internal SRAM at 0x08050000.
While in the bootloader main loop (POM still enabled) , I connect to the board using CCS 10.2 and a J-Link.
I load my application symbols and add the sy,bols for the bootloader.

The Debugger says "(no symbols are defined)", yet the disassembler appears to have symbols, but
no source code.


Will "connect" result in a reset?
Is there a way to avoid a reset. I want to connect to the running system and stop it.

If I open a Memory Window, the first 64kB of the flash memory seems to be all zeroes.
If I apply a manual reset without any probes attached, the bootloader starts and executes
normally so the flash at 0x00000000 is correct and not all zeroes.

If I look in a Memory Window at 0x08000000, it appears that the total memory is cleared.
If the POM is enabled and the memory is cleared, then it explains why the first 64kB is clear.

Why is the SRAM clear?
I do not have anything in my GEL files which seems to clear the RAM.
They are almost the default ones.

If I modify the memory at the overlay position 0x08050000 and then hit refresh in the disassemble window
it still reads out at 0x00000000. It is not changed.

If I open the disassemble window at 0x08050000, then changing the memory window affects the disassembly window.


Conclusion: The theory that the POM generates the problem does not seem to hold water.

The other unit I can see generating problem is the MPU

The bootloader sets up the first MPU region (0) to accept accesses to all flash

The second MPU region covers the first 64kB of the flash, and is set to allow read and execution, but block writes.

If the CPU is reset, then all MPU regions should be disabled, right?

Why would the debugger read out zeroes in the first 64 kB?