• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 82 subscribers
  • Views 645 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28034: bootloader problem

Howard Zou
Genius 12365 points
Part Number: TMS320F28034


Hi,

my customer has one boot code project and one app code project.

The flow for them to upgrade the app code is as below:

1. When upgrade request is received from SCI, the app code will erase the flag(to tell that the app need to be ugpraded), and then enable watchdog and trigger watchdog reset.

2. After watchdog reset, the code will go to code_start, here, we will check the Flag and then jump to boot code project c_int00, and after c_int00 we should go to BOOT code main(), here we finish loading APP code, and at the end of main() we will jump to APP c_int00, then it should go to APP main().

However, we have 20pcs out of 150pcs that could not correctly go to APP main(), but we are sure the new APP code is already loaded to the device since we have read out the memory and compare the results. So we guess the code got stuck somewhere in APP c_int00 and trigger illegal TRAP.

And we have unsoldered the bad device to the good board, the problem goes with the bad device.

We've no idea why it would stuck in APP c_int00. We guess it's because we have done twice c_int00, once boot c_int00, and once APP c_int00.

But why it will cause problem? And why the problem happens only on some devices?

  • 0
    TI__Guru* 93040 points

    Howard, 

    It will require some more debug to narrow down the issue.  

    Howard Zou said:
    We've no idea why it would stuck in APP c_int00. We guess it's because we have done twice c_int00, once boot c_int00, and once APP c_int00.

    It sounds like the basic flow works on most devices so I don't think having two c_int00's is necessarily the issue.  The question I'd ask is where exactly (and why) is the device getting stuck in the c_init00?  

    Can you try connecting to a 'stuck' device using CCS, load symbols only, reset, and debug where it becomes stuck?  What is the CPU trying to do and what causes it to be stuck - for example a loop index is wrong ? 

    Is it only stuck when going through the update flow, or is it also stuck when not updating  (i.e. is it stuck in both the 'yes' path and the 'no' path).

    Is this behavior something that recently started ? Was there a working flow previously that was changed?  Knowing what changed (if anything) can help narrow down the issue.

    I also suggest checking if any errata or usage notes apply to this situation.

    -Lori

  • 0 in reply to Lori Heustess
    TI__Genius 12365 points

    You asked: Can you try connecting to a 'stuck' device using CCS, load symbols only, reset, and debug where it becomes stuck?  What is the CPU trying to do and what causes it to be stuck - for example a loop index is wrong ? 

    My answer: It's stucked here

    You asked: Is it only stuck when going through the update flow, or is it also stuck when not updating  (i.e. is it stuck in both the 'yes' path and the 'no' path).

    My answer: it doesn't stuck when not updating.

    You asked: Is this behavior something that recently started ? Was there a working flow previously that was changed?  Knowing what changed (if anything) can help narrow down the issue.

    My answer: Previously, we will not directly branch to APP c_int00. We will write the Flag to 0x5A, and then trigger watchdog reset, And then it will go back to code_start and branch to APP c_int00. 

    That's why we suspect c_int00. Since with previous working flow, there will only be one c_int00 after code_start. With the new working flow, there will be 2 c_int00 executed.

    We suspect c_int00 because we guess it will occupy part of RAM and write some specific value, and for the BOOT c_int00, it will occupy some part of RAM, and if we directly branch to APP c_int00, it may also occupy some part of RAM and it may conflict the the area used by BOOT c_int00.

    I wish that you could confirm what I suspect is not possible and the problem should not be related to RAM then I could look into other reason.

  • 0 in reply to Howard Zou
    TI__Guru* 93040 points
    Howard Zou said:

    My answer: It's stucked here

    This seems to be an infinite loop within the application code.  The assembly says "branch to label FXM_F_selfLoop unconditionally".   Since FXM_F_selfLoop is that same location it just loops.  If the code lands here it will loop forever (which it is doing) unless the watchdog times out. 

    I don't think FXM_F_selfLoop is part of the c_init00.   Can you confirm that FXM_F_selfLoop is part of the application code?  The .map file will help here as it will show what is mapped to that memory location. If this is in the application code, how does the CPU end-up in this forever while loop? Or is it expected to end-up here but something should be happening in the system that is not?

    Howard Zou said:
    We suspect c_int00 because we guess it will occupy part of RAM and write some specific value, and for the BOOT c_int00, it will occupy some part of RAM, and if we directly branch to APP c_int00, it may also occupy some part of RAM and it may conflict the the area used by BOOT c_int00.

    I suggest checking the .map files for any conflicts in memory usage between the different initializations.  Another suggestion is to dump out memory after the init in the working case and compare it to the non-working case. 

  • 0 in reply to Lori Heustess
    TI__Genius 12365 points

    Hi,

    we dumped the RAM and Flash out for good device and bad device with CCS memory browser after init. Good device and bad device flash seems the same(I just roughly checked since I don't have software to compare 2 bin files), but RAM are different.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/good-device-whole-flash.binhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/good-device0x0_7E00_0x400.binhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/good-device0x8000_7E00_0xA000.binhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/bad-device-whole-flash.binhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/bad-device-0x0_7E00_0x400.binhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/bad-device-0x8000_7E00_0xA000.bin

    The memory map of the boot and app code are as below: boot reside in flash sector A, app reside in the rest sectors.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/APP.maphttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/Boot.map

  • 0 in reply to Howard Zou
    TI__Guru* 93040 points

    Howard I’ll look at the info you sent and get back to you on Monday. 

  • 0 in reply to Howard Zou
    TI__Guru* 93040 points

    Howard, 

    Lori Heustess said:
    I don't think FXM_F_selfLoop is part of the c_init00.   Can you confirm that FXM_F_selfLoop is part of the application code?  The .map file will help here as it will show what is mapped to that memory location. If this is in the application code, how does the CPU end-up in this forever while loop? Or is it expected to end-up here but something should be happening in the system that is not?

    Any feedback on this question?  Looks like it is in both the app.map and the boot.map.  

    Howard Zou said:
    but RAM are different

    Ok - is it RAM that is actually being used? 

    Does the application assume a ram location is a specific value without having set an initial value?  For example - if a location is assumed to be zero on power-up. This may be true on some devices but not on others.  On this device RAM is in an unknown state after power-up.

  • 0 in reply to Lori Heustess
    TI__Genius 12365 points

    Any feedback on this question?  Looks like it is in both the app.map and the boot.map. 

    Howard: It seems that FXM_F_selfLoop is neither in app.map nor in boot.map, I can't find it in either map file.

    Does the application assume a ram location is a specific value without having set an initial value?  For example - if a location is assumed to be zero on power-up. This may be true on some devices but not on others.  On this device RAM is in an unknown state after power-up.

    Howard: I'm not sure, what kind of code will assume a ram location to be a specific value? How can I zero all the RAM with our own code?

  • 0 in reply to Howard Zou
    TI__Guru* 93040 points
    Howard Zou said:
    FXM_F_selfLoop

    Howard,  There was a typo - my question is about FXN_F_selfLoop.  It is the function shown in the disassembly you shared with the loop forever.

    Howard Zou said:
    Howard: I'm not sure, what kind of code will assume a ram location to be a specific value? How can I zero all the RAM with our own code?

    An example - if code says if(x == 0) but x was never initialized the code is assuming it is either 0 or non-zero - neither is deterministic after power-up.  Instead the code should init the variable.

    My goal is to give ideas for debugging the problem.  I really feel the customer should try to recreate the scenario with Code Composer Studio connected.  Set a hardware breakpoint where that infinite loop function is called from and see why the code goes there.  

  • 0 in reply to Lori Heustess
    TI__Genius 12365 points

    Lori,

    I'm sure that the FXN_F_selfLoop is called from boot because the address is 0x3f6b83, which matches the boot map file.

    But I don't know how to debug to see how it ends up FXN_F_selfLoop.

    We have set a breakpoint at LB c_int00 of boot code, it can stop there, and then we click resume icon, it will end up at FXN_F_selfLoop.

    We don't know where we could find c_int00 source file and we are not able to do step by step debug with CCS.

  • 0 in reply to Howard Zou
    TI__Guru* 93040 points
    Howard Zou said:
    I'm sure that the FXN_F_selfLoop is called from boot because the address is 0x3f6b83, which matches the boot map file

    I believe I also saw this function listed in the app .map file ?

    Howard Zou said:

    We have set a breakpoint at LB c_int00 of boot code, it can stop there, and then we click resume icon, it will end up at FXN_F_selfLoop.

    We don't know where we could find c_int00 source file and we are not able to do step by step debug with CCS.

    This is part of the compiler source code.  When CCS askes for the source, browse to the location of the compiler install.   This may be under the CCS directory (C:\ti\ccs1031\ccs\tools\compiler......) but depends on the install.  Examining the project properties can help you find it:

  • 0 in reply to Lori Heustess
    TI__Guru* 93040 points
    Lori Heustess said:
    I'm sure that the FXN_F_selfLoop is called from boot because the address is 0x3f6b83, which matches the boot map file

    I believe I also saw this function listed in the app .map file ?

    oh I see.  The address is the same as the boot .map.  Understood.