• State Resolved
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 166 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

TMS320F28379D: Boot Rom and WatchDog

TMS320F28379D: TMS320F28379D: Boot Rom and WatchDog, CAN compability

vincent liebart
Intellectual 500 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Tool/software:

Hello,

It's me, again.

I closed this issue, because the explanation was very clear (many thanks)

So, I started to include that into my project, but it did not work. Why ? My project includes CAN functionality. So, I join the same example as resolved, but with CAN addition.

And let me explain down below what happens:

1) The project is the same as before, but I added a CAN peripheral in the SysConfig. I will not use it. I just want the project to initialize this peripheral in board.c:

2) I launch a debug session with FLASH configuration. So, when the CPU2 will reset, it will not erase the code in RAM, which is usefull for the code start

3) Before to run each core, I launch the script EMU_BOOT_FLASH and check that 0xOB5A is written at the adresses 0xD00:

(CPU1)

(CPU2)

3) When setting the variable uint16_Freeze, the CPU1 enters into a infinite while loop, and the ISR of the Watchdog asks for a reset of the CPU1 and CPU2:

4) I cannot see any error message in the debug session, but I clearly see that the programm does not run anymore

If I set the CPU2 on pause, I can see that the programm is blocked in the CAN RAM init function:

I suppose that the problem is linked to the RAM erasing.

Can somebody tell me exactly what is wrong ? Will it happen in the standalone configuration ? How can I do to test the watchdog fonctionnality in a debug session ?

Thank you.

2025_08_04_TISupport.zip

  • 0
    TI__Mastermind 18285 points

    Hi Vincent,

    Let me loop in the watchdog expert to comment on this.

    Best Regards,

    Delaney

  • 0
    TI__Genius 12945 points

    Hi,

    CPU1 WDRSn causes XRSn.

    CPU2 WDRSn just causes CPU2 reset.

    XRSn clears the 0xD00 or not, that we need to check. On XRSn assertion BootROM runs after so need to step through and confirm the same, assigning thread back to Bootrom experts.

    Standalone configuration doesn't rely on 0xD00, the boot mode in standalone config is decided by boot mode pins or OTP configurations.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Intellectual 500 points

    Hello Prarthan,

    I am sorry, I answered you just before your messsage, but I cannot see my message.

    So, let me explain again. Maybe you can go and see the original question. I am aware of the reset processing. One of your colleague helped me a lot.

    But Can you take a look of my archive, or maybe just read what happen if the beginning of my programm contains a RAM initialization (for CAN).

    I expect that the erasing of the RAM is done before this initialization, but it seems that there is a conflict between the two operations.

    I am in vacation in two days, for 2 weeks. So, if you aswer me next week, don't be surprise that I do not give you some news. This issue is really important for me, and I will manage it when I will be back.

    Vincent

  • 0 in reply to vincent liebart
    TI__Genius 9905 points

    Hi Vincent, 

    To keep you updated: I will take a look at it tomorrow and see if I can replicate. 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    TI__Genius 9905 points

    Hi Vincent,

    I observed the same CAN initialization issue for CPU2. I resolved the issue by moving the "board_init()" function call in the CPU2 project after the IPC sync. This allows CPU1 to properly connect the CAN peripheral to CPU2 before synchronization. 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Intellectual 500 points

    Hello Matt,

    Thank you for spending some time to test the archive. Your solution works.

    But ... can you tell me why ? It looks more logic to place the IPC_sync function after the board init to have a better synchronization between the two cores, and this way does work without the watchdog issue.

  • 0 in reply to vincent liebart
    TI__Genius 9905 points

    Hello,

    I'm glad the solution works for you too.

    CPU1 needs to allocate the CAN module to CPU2 before CPU2 can operate on it. Allocation of core to a peripheral can only be done in CPU1. The IPC synchronization guarantees that the CAN module is properly assigned to CPU2 as owner before CPU2 begins initialization the module with board_init().

    Please let me know if that makes sense. 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Intellectual 500 points

    Hello Matt,

    That makes sense to me, but I've still wondering why every thing was fine at a first power on.

    Since it dealed with the RAM initialization for CAN, I thought it was a side effect of the reset of CPU2 by CPU1.

    So I did a test: 

    - I let the board_init() in CPU2 before the IPC_sync() function

    - I just put a delay before board_init()

    So, when the CPU1 resets, it has time to assign CAN module to CPU2 before CPU2 tries to initialize the CAN memory in board_init().

    And it works.

    So my conclusion is that the reset/wake up of CPU2 at the power ON is slower than its reset on CPU1 request.

    Can I ask you the same question:

    Please let me know if that makes sense

    Thank you for your help.

    Vince.

  • +1 in reply to vincent liebart
    TI__Genius 9905 points

    Hello Vince,

    That makes sense.  

    The reason why the board_init() is generally put after the synchronization mechanism (in C2000Ware example code) is to eliminate any possible race conditions between CPU1 and CPU2 during initialization. Adding delay before CPU2 calls board_init() increases that margin, but doesn't completely solve the issue.

    Best,

    Matt