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.

TMS320F28379D: c_int00 after a customized bootloader program

Part Number: TMS320F28379D

Dear team:

Background:  We customized a bootloader which always runs when power up. Besides, in our application code, we can also jump into the bootloader with a USB command.

 

In the bootloader we did several tests:

 

1) Flash the app code and jump into app, this will work with no problem.

2) If we flash the code repeatedly (more than once), the code can still be flash and the jump can success. But in app, all the interrupt cannot work.

 

In the .CMD file, the application code memory BEGIN is allocated at the begin of FLASH E.  And we simply jump to this address after the bootloader.

Is it ok to jump to the beginning of application code directly? Did we miss any initialization procedure which caused the problem? If we missed something, why we the code works normally if we only flash once?

 

We hope to solve this problem just in case users accidently flash the MCU twice, and the code cannot work normally, which will cause unpredictable problem.

------------------------------------------------------------------------------------------------

And in fact you have already given me some advice:

"Fourth, it is fine to jump straight to the application code. But what do you mean by the application code? Are you jumping to BEGIN which contains code_start and then performs a LB to _c_int00? You need to make sure _c_int00 is being executed before branching to main() of the flash application. This performs the C initialization code."

 

This is exactly what we did, we are jumping to BEGIN which contains code_start and a LB to c_int00 operation.

 

And we noticed in this post, you suggest not to jump to c_int00 but the entrypoint like the example code did.

 

e2e.ti.com/.../1530413 c_int00#1530413

 

My question is:

1) Does the code in the entrypoint contains a c_int00? Or in other word, is the entrypoint address equals to BEGIN address?

2) Is it OK to execute c_int00 twice (once before bootloader and once before application code)? Did this caused the error?


  • By the way, in which way do you suggest to achieve the jumping between bootloader and app code?
    In our code, we just assign the BEGIN of bootloader in FLASH A and the BEGIN of app code in FLASH E. And jump to the corresponding BEGIN address. Is that OK?
  • Hello

    Yes, your entry point address should be where c_init00 is placed. I am not aware of any issue with running c_init00 twice.
    Your method of jumping between app and bootloader sounds acceptable and common to how it is typically done.
    I am not sure why it works when initially is flashed. Make sure you are initializing the PIE and vector table when running the app after jumping.

    Best regards
    Chris
  •  Hi Chris,

    To help identify the error, we did the following experiment:

    The interrupt is generated by EPWM1, so we observed the ETFLG register and IFR in PIE.

    As you can see, the ETFLG is set at the right point, while the IFR & PIEIFR is still all 0, which I think may cause the problem.

    So, there must be some incorrect configuration in the mechanism of reporting ETFLG to corresponding IFR. What can resist the ETFLG to reflect on IFR?

    Thanks.

  • And I noticed this post:
    e2e.ti.com/.../625274

    It mentioned the PIEIFR was triggered at the falling edge, which falling edge refers to?
    I am guessing, if ETFLG remains 1 during the bootloader process, and PIEIFR cannot be trigger because the lack of 'falling edge', will this cause the problem?
  • Hello

    Thank you, that is helpful information. I am syncing with PIE experts and will get back to you.

    Best regards
    Chris
  • Maybe it has something to do with an uncleared PIEACK preventing the interrupt from propagating? What's the status of PIEACK when in this state?

    (edit: Just wanted to note that I realized that the PIEACK prevents the CPU IFR from being set, not the PIEIFR, so this was not a likely cause for this particular issue.)

    Whitney

  • Hi Chris and Whitney,

    We disabled all the interrupt before calling the bootloader and cleared the related peripheral int flag bits when jumping back to application code. And now the problem is solved.
    We thought the PIEIFR is a directly reflection of peripheral int flag. But the fact is PIEIFR is triggered by the falling edge of peripheral int signal, is that correct?
  • Yes, it is triggered by the falling edge. Take a look at the "Event-Trigger Interrupt Generator" block diagram in the TRM. A pulse is generated on the interrupt signal that goes to the PIE, and the ETFLG is latched.

    Whitney