Hello,
I'm working on a project using a FRDM-KL82Z board, with the MKL82Z128 microcontroller. I use the SEGGER J-Link EDU programmer and MCUXpresso 10.0.2 IDE.
My project is very simple, I don't use FreeRTOS (although it will in the future), and it just uses the multi-color LED and the buttons on the board. You'll see that the project name is Bootloader_Dummy but at the moment it does nothing related to a bootloader.
I've tried using the "on-board" OpenSDA to debug through the USB connector, but I need to make it work through the SWD as the final product won't have any of the board peripherals, just de MCU.
- If I debug with OpenSDA it works just fine. It stops at the first line of main() and everything works like a charm.
- If I flash the .hex file with de SEGGER J-Flash Lite it works as well. This makes me think that the 20-ìn to 10-pin manual adapter is correct. For those interested, that's how I made the program automatically create an .hex file:
- PROBLEM: If I debug using the J-Link, I never get to main(), but the processor goes to adresses outside the Flash Memory Space.
While looking for a reason, I've found this information:
- I tried following the start-up procedure line by line. My first surprise is that the CPU doesn't go directly to the ResetISR as I thought it should be (at least it doesn't stop at eh breakpoint). It stops at the __section_table_start which is one of the first lines after the IVT. Then in data_init is does a "push {r4,lr}" and later "pop {r4, pc}". "lr" has an address that belongs to SRAM, so the program goes there (It has this value since the first breakpoint at least, and it's there every time I've tried). After that instruction it enters in the HardFault_Handler.
- I tried using "Erase Chip" in the J-Link Flash Lite, then debugging and checking if the content that "Memory Browser" from the IDE shows is the same as the .hex I previously flashed. I've compared the values in a big number of positions all around the flash memory and it seems to be OK. I'm working on a Python script to compare them, but I'm pretty sure there's no difference. If it was a writing/reading error I'd expect a whole block of bytes to have a different value.
- After the "Erase Chip", if I try to debug again the CPU goes to an address that's in the Boot ROM Space, and executes BOOT code. I'm talking about the default Bootloader that comes with the MCU. This time the CPU doesn't even stop at the start-up sections it used to stop at, so I don't know what happens.
- I thought there may be some kind of collision between the J-Link and the OpenSDA, so I tried to disconnect the J6 and J7 jumpers in the board, as they connect the OpenSDA to the MCU. If the board is not powered through the OpenSDA Micro USB, there's a connection failure (ERROR: InitTarget(): PCode returned with error code -1). If the OpenSDA is powered through its Micro USB connector, it doesn't matter how the J6 and J7 jumpers are connected.
Finally, this is my Debug configuration:
Does anyone know what is happening or what I should try?
Thanks a lot.
Josep.
Hello Josep,
I test the demo code under KSDK, it can work well. The connection as beblow:
Could you also test a demo project ?
BR
Alice
