• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 223 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.

TMS320F28386D: CMPSS and CLB assigned to CPU2 causing NMWI reset

Marco Martines
Prodigy 30 points
Part Number: TMS320F28386D


Tool/software:

Hi Everyone,

I'm currently facing an issue with a board equipped with F28386D where the code is not starting.
While using the same code on the DemoBoard is all fine.
I tried also with a LED example code and also this one is not booting on my board.

By looking at XRSTn signal I can see a drop to GND every 15ms with a duration of 25us (we are using 200MHz clock) which suggest me the watchdog intervention.
The WD is disabled from the .asm file

WD_DISABLE  .set  1    ;set to 1 to disable WD, else set to 0

so this makes me think that it is the NMWI that reset the uP.

By adding some while(1) loops in the code I identified that the code is running until these 2 lines
  DevCfgRegs.CPUSEL15.all = 0x000000FFU;
  DevCfgRegs.CPUSEL12.all = 0x000000FFU;

which are generated by the Build from Matlab/Simulink that should associate CMPSS and CLB to CPU2.

My code, which runs only on CPU1, is not using such peripherals so it makes sense that are not associate to CPU1.
If I comment these two lines everything is fine and my code is able to boot and run perfectly on my board.

What is not clear to me is why I have to comment such lines and why I get a different behavior from the demo board.
Any ideas on this? I'm questioning both HW and SW/Configuration issue.

Additionally, for a code that is not using CPU2 and CM what is the best thing to do? Erase the flash of such CPUs and leave it unprogrammed? 

  • 0
    Prodigy 30 points

    For info by adding a DELAY of 20us before the CPUSEL commands I was able to keep the two lines uncommented without having resets.
    While if I use 10us of delay It is still resetting



    And actually this file (Matlab generated) looks in the opposite order from what suggested from Tech reference

    but If I invert the PCLKR and CPUSEL calls, even keeping the delay, it is resetting.

    Maybe this gives you some more information for the issue.

  • 0 in reply to Marco Martines
    Prodigy 30 points

    By adjusting some inductance values, we reduced the rise time of the 3.3V line. This change was sufficient to allow the microprocessor to operate correctly without entering an infinite loop—likely having a similar effect to the 20µs delay.

    What remains unclear is why, without this fix, the system keeps rebooting. I would have expected that after the first watchdog intervention, the uP would find both the 3.3V and 1.2V lines already stable and continue running normally.