• State Resolved
  • Replies 9 replies
  • Subscribers 53 subscribers
  • Views 224 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM33-SDK: SW unfunctionning after changed the SDK version

Sebastien Le Diouris
Prodigy 160 points

Part Number: MSPM33-SDK
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am working on a project with MPSM33C321A, I work on Code Composer Studio.

I have a project, where inside there is PWM, ADC, MCAN, SPI etc ...

I work with SDK 1.3.0.01

image.png

But when I update the SDK to version 1.4.0.00

image.png

I clear and compile the project, and download it and run it, in debug mode, I see the SW stays in the loop here:

image.png

in this MCAN function:

image.png

 

Could you tell me why ?

 

Thanks

  • 0 in reply to Sebastien Le Diouris
    TI__Prodigy 210 points
    Hi Sebastien,
    In SDK 1.4.0.00, SysConfig attempts to configure MCAN before the Message RAM initialization is fully complete. Consequently, the hardware state machine locks up, and getOpMode() gets stuck indefinitely in SW_INIT mode. So we can manually reset the MCAN0 module and add a startup delay in main.c before SYSCFG_DL_init() runs. 
    Something like this:
    DL_MCAN_reset(MCAN0_INST);
delay_cycles(16);
DL_MCAN_disablePower(MCAN0_INST);
delay_cycles(32);
DL_MCAN_enablePower(MCAN0_INST);
delay_cycles(4000); // Wait for Message RAM initialization, about 50us. If CPU frequency is 80MHz, the cycles are 4000.
SYSCFG_DL_init();
    Hope the method can resolve your problem. Thanks!
    Best Regards,
    Ella Tang
  • 0 in reply to Ella Tang
    Prodigy 160 points

    Hello Ella,

    thanks for your response, but unfortunetly, it is not better

    Do you confirm you requested me to do this ?

    Thanks

  • 0 in reply to Sebastien Le Diouris
    TI__Prodigy 210 points

    Hi Sebastien,

    Since this approach did not resolve the issue, let's revert the code back to its original state first to pinpoint the exact root cause. Then, please let the code run until it gets stuck, and export the hexadecimal values of the following four registers via the Registers window in CCS:  CCR, PSR, ECR.

    For example:

    Thanks and Best Regards,

    Ella Tang

  • 0 in reply to Ella Tang
    Prodigy 160 points

    Hello Ella,

    please find below the values 

    Best regards

    Sebastien

  • 0 in reply to Sebastien Le Diouris
    TI__Prodigy 210 points
    Hi Sebastien,
    We currently suspect a potential conflict in the initialization sequence. Could you please check inside the SYSCFG_DL_init() function?
    If SYSCFG_DL_MCAN0_init() is called before SYSCFG_DL_SYSCTL_CLK_init(), please swap their order to ensure that SYSCFG_DL_MCAN0_init() is called after the clock initialization.
    For example:
    Under this configuration, does the debug session still fail to work properly? If it remains stuck, what are the values of those registers at this point?

    Thanks and Best Regards,

    Ella Tang

  • 0 in reply to Ella Tang
    Prodigy 160 points

    Hello Ella,

    yes I have MCAN_init, done before SYSCTL clock.

    But how do you do to not generate automatically the file "ti_msp_dl_config.c" ? 

    thanks

  • 0 in reply to Sebastien Le Diouris
    TI__Prodigy 210 points

    Hi Sebastien,

    Regarding the ti_msp_dl_config.c and ti_msp_dl_config.h files, we can close the "Include in build" and save files to our project root folder, then we can modify the files directly.

    Like this:

    Thanks and Best Regards,

    Ella Tang

  • +1 in reply to Ella Tang
    Prodigy 160 points

    Hello Ella,

    now it works, but not because I have done your modification but because I changed the source clock, before I used SYSOCS and I changed by crystal (external clock)

    Thanks for your help, I close the topic