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.

TMS320F28388D: Jumping from bootloader to app works on debugger but doesn't work when booting from flash

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hello!

I have an app image in the internal flash of CPU1. This image begins at address 0x90000 (not the default reset address). To the reset address I download a program that does (almost) nothing except jump to address 0x90000 using asm(" LB #90000h"). When I run the program at the reset address from debugger the app (just a modification of the blinky example) works fine. If I boot from flash there is a reset and the app doesn't start.

Do you have any idea what is the difference? Is it possible that the flash is somehow in secure mode? I read in some other thread for another C2000 that there could be an issue with including RTS. Does that even make sense? It does work from debugger.

The things that are done before jumping:

Disable WD, copy functions including wait_us  to ram. I tried other versions also like servicing the WD right before and after the jump, jumping directly to _c_int00 of the app image without passing through the LB in 0x90000 and many other combinations. 

Thank you for your help!

Rachel

  • Flash may not be in secure mode unless you intentionally configured user OTP like that.

    1. when you flash the application at 0x80000 (default configuration supplied in C2000ware) is it working ? this will help us confirm that there is nothing wrong with boot rom execution.
    2. what are the instruction you used to jump from 0x80000 to 0x90000. have you verified that these are working ?
    3. when you say reset what is the program counter value
  • Thank you for your answer. I am glad it can't be secure mode.

    Regarding your questions:

    1. Before I minimized my application at 0x80000 it was my boot loader. It responds in UART. When I hit enter I get a prompt, I used it to program the app in address 0x90000 and I had a special uart command for the jump to 0x90000. I also had a LED on. When I run the same minimized program from debugger I can step into it and see the jump. Depending on the order between the jump, memcopy(ramfuncs...) and InitSysCtrl it will either jump correctly to 0x90000 and run correctly or go to ESTOP after the branch. Of course I only run from flash the option that worked on debugger.

    2. I used two options that seem to work the same: asm("LB #90000h") or initializing a function pointer to 0x90000 and then calling the function.

    3. I can't read the PC value since it only happens when booting in flash mode. To connect a debugger I would have to cycle power. Anyway I know that the program in 0x80000 just starts over when there is a program there doing more than just  a jump. I can see the LED being off for a moment and going back on again and then the bootloader responds to uart. With my minimal program that only jumps my indication for reset is that I have a relay on the board and I hear it click. As I am writing these lines I am wondering why I only hear it click once. I would expect it to go back to the beignning at 0x80000 and jump again. I will only be near the hardware in a few hours. I will repeat the experiment and listen carefully. Will update if there are more clicks.

    Thanks again,

    Rachel

  • as i understand boot rom jumps to code at 0x80000 consistently. There is no issue with this.

    You are seeing problem when jumping from bootloader to application (at 0x90000). am i correct ?

    when you say minimized application, is it something like a simple while (1) loop ?. And in this case you could see program counter jumping to 0x90000.

    when you put actual application you are seeing the issue. Please confirm if my understanding is correct. 

  • No issue with jumping to 0x80000.

    My "minimized" project is actually my bootloader, only one of the first lines in main() is the jump. When running in debugger I can see the program counter jumping to 0x90000.

    It seems that the issue does not depend on the code on 0x90000. I use the blinky example because it's much smaller then my actual application project. The problem with the jump will occur whether I am using my full bootloader with a uart command to jump, or I am using a jump at the beginning of main.

  • I ran the program again from flash and then connected to the board using debugger. PC was 0x3FD2AE. I understand it is in the boot rom. As in other cases, the debug window shows the following message:

    sendAndReceiveBytes_spi(struct SPI_DRIVER_STRUCT*, unsigned char*, unsigned char*, unsigned short, unsigned short)() 0x3FD2AE (an error occured: failed to parse the previous frame FP)

    This function is indeed called in the 0x80000 project, but this call is not even reached. It does not appear in the blinky project.

  • so the current sequence is a simple jump from program at 0x80000 to 0x90000.

    you mentioned that this is working with debugger connected. And you have disabled watchdog as well.

    so i dont see a reason why it wont jump to 0x90000.

    the above understanding indicates that something failed in program at 0x90000 and the program counter went to error handler in boot rom.

    also please check from memory window that the program at 0x80000 and 0x90000 are intact and not overwritten by something else.

  • After some more investigating I realized that probably due to the way I allocated ram in the program in 0x90000 the functions that had to run from RAM did not have enough memory. At least re-allocating RAM made the jump work. Do you think the way I explain this to myself make sense? Can you give a better explanation? I would really like to use this problem to learn something. Thank you for all the help!

  • yes that makes sense. As i mentioned in my previous response the jump from bootloader at 0x80000 to application at 0x90000 happened as expected.

    Some failure in the application caused the jump to boot rom.

    if this is the case when you run your application with debugger connected you should see the same issue.