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.

MSPM0G3519: Factory region data causing exception in MSPM0G3519 - MCAL example

Part Number: MSPM0G3519

Tool/software:

Hello Team,

we were trying to run example provided in MCAL package MCAL_MSPM0_00.02.04.00. The example is not working as expected, as MCU goes into exception (reset handler).

We have following observation:

1. CCS example: out_of_box_mspm0g3519

We flash binary of out_of_box_mspm0g3519 example provided in CCS and we can see code is running with LED blinking on the board. In this case we can see address 0x41C40034 is having value of 0x8103060A

2. MCAL Package example - dio_app

We build example according to provided steps in MCAL release notes. We downloaded the generated binary file through Lauterbach (Trace32) debugger. 

when we run the example, instructions till SYSCTL->SOCLOCK.SYSPLLPARAM0 = *(volatile uint32_t *) ((uint32_t)Mcu_DrvObj->Mcu_ClockSrcConfig->Mcu_ClkSysPLLInputFreq); (in Mcu_SyspllSetting() function) get executed. As soon as above-mentioned line executes it jumps to reset handler function. Further we checked and found that there is no data on address 0x41C40034 which is available in case of CCS example.

Based on above observations we have below questions:

1. Is this Flash region written while flashing code from CCS. How it's handled?

2. Do we need to take care of writing this area while flashing. How can we handle it?

3. Or is there any reason which is affecting this?

Regards,

Rohidas

  • 1. Is this Flash region written while flashing code from CCS. How it's handled?
    SYSCTL->SOCLOCK.SYSPLLPARAM0 = *(volatile uint32_t *) ((uint32_t)Mcu_DrvObj->Mcu_ClockSrcConfig->Mcu_ClkSysPLLInputFreq); (in Mcu_SyspllSetting() function)

    This region is Mcu_ClkSysPLLInputFreqType, address is 0x41C4001C.... in Mcu_Cfg.h

    This is factory region.

    2. Do we need to take care of writing this area while flashing. How can we handle it?

    We need to take care of this region when read from them.

    Will do it in software code in driver layer.

    3. Or is there any reason which is affecting this?

    FLASH_ERR_01 in https://www.ti.com/lit/er/slaz758a/slaz758a.pdf.

    How to fix:

    1. Check you CPU speed.

    2. If speed is 32MHz, set Flash wait status to 1, you can access factory region freely.

    2.1 If speed is 80MHz, need to set CPU to 32MHz, Flash wait status to 1, to access this region.

    3. There are workaround when using a standard MSPM0 demo from SDK with syscfg.

    syscfg will generate the code to reset clock system configuration to 32MHz wo copy this region's data to RAM, then running clock system init.

    Regards,

    Helic

  • Hello Helic,

    These answers are not clear.

    1. Is this Flash region written while flashing code from CCS. How it's handled? Yes, its factory region bit does this written by CCS when board connected?

    2. Do we need to take care of writing this area while flashing. How can we handle it? For this you are saying we need to take care while reading. But we are not clear how to handle it while using MCAL package code. We are not using CCS currently.

    3. Or is there any reason which is affecting this? For this question, you have given steps for fix. How we can add this fix in MCAL package code. 

    Regards,

    Rohidas Khurange

  • 1. Is this Flash region written while flashing code from CCS. How it's handled? Yes, its factory region bit does this written by CCS when board connected?

    No, it's not. This region is written in factory, it's constant.

    2. Do we need to take care of writing this area while flashing. How can we handle it? For this you are saying we need to take care while reading. But we are not clear how to handle it while using MCAL package code. We are not using CCS currently.

    You can't write this part.

    For this you are saying we need to take care while reading. But we are not clear how to handle it while using MCAL package code. We are not using CCS currently.

    I need to check this internally.

    Or is there any reason which is affecting this? For this question, you have given steps for fix. How we can add this fix in MCAL package code. 

    There will be MCAL package update to fix this.

    This is a factory region access bug of MSPM0G3519.

    Regards,

    Helic

  • I also need to confirm your use case.

    Can you send me the detailed information about:

    CPU clock frequency.

    How your syspll setup.

    Help me to confirm the Flash wait status bit when run the code below:

    SYSCTL->SOCLOCK.SYSPLLPARAM0 = *(volatile uint32_t *) ((uint32_t)Mcu_DrvObj->Mcu_ClockSrcConfig->Mcu_ClkSysPLLInputFreq);

    Do you use the debugger re-start function when this hardfault/resethandler issue happens?

  • Hello Helic,

    Thanks for the response. 

    All the issues reported above resolved with internal MCAL release.

    Thanks a lot!

    Regards,

    Rohidas