Where is my code downloaded to on LPC1820 which is a flashless part?

[richardchenigt]

Hello, I have a question on how the code downloading works on LPC1820 (a flashless part). In my configuration, I used a 512KB external boot prom to host the firmware for this processor, and I am using Keil IDE to debug it. My question is where on the processor my code gets downloaded to when I debug it? Usually the code will be downloaded to the internal flash of the MCU and MCU resets after the download to execute the code from the flash, since LPC1820 has no internal flash, where doe my code go and how its debugging work??

My speculation is that the code is downloaded to SRAM within LPC1820, then the debugger is modifying the shadow register so that the above SRAM can be remapped to the address 0x00000000, can you confirm? How can I read the Shadow register for this purpose?

Thanks

Richard

[bernhardfink]

1. When it comes to execution of code from memory, then it doesn't matter where the memory is and what technology it is. The main point is that the ARM can see this memory directly on the bus. For the LPC1800 this is the case for the internal memory (flash and SRAM), for SRAM and SDRAM on the external bus, for parallel NOR flash on the external bus and for the QSPI flashes connected at the SPIFI.
2. Memory where the ARM could not execute from:  NAND flash, seriel flash on SPI bus.

For a debug session this means the following: 

• Your executable code (= the binary, generated out of the ELF file) must be somewhere in memory defined in 1). The way it went there is in principle a completely different step. You can program it into flash with a tool, you can make a serial download using ISP programming, you can use the JTAG tool using the functionality built into the debugger (take care, you don't use it as a debugger, you use it as a download channel over JTAG), you can program the QSPI externally and put it then on the board etc etc.
  Finally the executable code just needs to be there, linked for this memory region.
• IDEs offer mostly a comfortable procedure for starting a debug session:  build the image + download the binary / flash the binary + start the debugger. But each step is an own task. So when you say that the debugger downloads code to the flash, then this is not completely true. The IDE uses a procedure to download code by means of the JTAG connection and programs it into the flash, but  in a first step this has nothing to do with debugging. A direct writing into memory (call it download) is only possible for RAM.
• For a comfortable debugging session the debugger must know the image (= the ELF file), which can have integrated debug information) and must know its linker map.
• When you start the debug session, the debugger reads out the physical memory region (= the binary) and compares it to the  data from the ELF file. If it matches, then the debugger program knows the relation between the code in the MCU and the ELF image with debug information.
• Then you can debug, every time you make a step in the code, information goes up and down the JTAG connection to align the two instances of the code, the one in the MCU and the one in the debugger program.

Concretely for the LPC1820 this means, that you create a program which is linked to the SPIFI memory region, you program it into the flash (or call it downloading into flash) and then you start the debugger.

Alternatively you can also create a program linked to the internal SRAM region and start the debugger. The debugger downloads the binary part of the ELF file into the SRAM (no need to read it back) and then you can debug.

A "bare metal debug session" would be, if you have code in the flash which the debugger doesn't know, so it does not have the relation to an ELF file with its debug information. Then you just start the debugger without loading such an ELF file into the debugger and you set the program counter to the beginning of this flash image. The debugger will read the binary image from the flash memory, disassembles it and then you can make steps in the code, but just on assembler level and without any support through debug symbols.

You can do this for example for the ROM code inside the LPC1820 (Boot ROM), where you don't have source code and also no ELF file.

Maybe the above described steps vary in one or the other area depending on the debugger implementation, but in principle this is the flow. Hope this help a little bit.

Regards,

Bernhard.

[richardchenigt]

Bernhard, thanks for the great insights on how downloading and debugging work, which is very helpful. One more step though, for LPC1820 (which is a flashless part), will my binary gets downloaded to SRAM within the MCI?

Thanks

Richard

[bernhardfink]

When you have an external ROM (Quad SPI flash or parallel NOR flash) with your program binary in it and you debug this code, then nothing gets downloaded to the MCU.

The MCU executes the program binary, the debugger software on the PC knows the program binary and its structure, and under control of JTAG these two instances run in parallel.

If you don't have an outside memory, then of course you need to bring your program binary into the internal SRAM. And then it's just the same as it would be in another memory, it is simply there, available for the ARM for execution.

Regards,

Bernhard.

[richardchenigt]

Thank you Bernhard for the great information! I do have an external QSPI flash on my target board, however it contains a different image from what to be debugged, will the new image be downloaded to SRAM in that case? Will the debugger detect that the image in external QSPI flash is different so it won't use it?

PS: Can you please point me to some reading/links on how Debugger works internally? 

Thanks again,

Richard

[Alice_Yang]

Hello Richard CHEN,

You can use external flash through SPIFI, there is software driver library support under LPCopen.

About detail please refer to User Manual->Chapter 21: LPC18xx SPI Flash Interface (SPIFI).

It support execute-in-place (direct code execution from the SPI Flash memory) and 

general read/write/erase operations.

There is a SPIFI introduction: LPC key feature_SPIFI 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[richardchenigt]

Thanks Alice, what I try to understand is where my code is downloaded to with MCU during debugging process.

Richard