RM48L952: Unable to Re-flash after Halcogen changes

Hi Dennis,

We started working on your issue and will provide an update soon.

--

Thanks & regards,
Jagadish.

Hi Dennis,

If it is caused by the invalid code, please try this procedure to let CPU enter a debug state:

1. Open the target configuration window, and launch the selected the configuration
2. Switch to debug window.
3. Press the reset (nRST) button and hold it.
4. Click “Connect Target” immediately after you release the nRST button.
5. The board should be connected after couple tries.

--

Thanks & regards,
Jagadish.

Thanks Jagadish.  As shown in the attached file, I had tried that, with CCS, IAR and Segger's J-Link flash.  Will attempt this again with CCS.

I attempted for another 15 maybe 20 minutes without success.

I attached two zips, one is halcogen source that works and the other is what breaks.  In particular it is the system.c file that causes it all.  The main difference between the devkit and our production board is the oscillator we use is 8MHZ.   When our production board broke, that is the only thing that I was changing, adjusting timing for the oscillator difference and appropriate RTI settings for the interrupts desired.

Hi Dennis,

Did you correctly calculated the LOAD capacitance for crystal, can you please refer below thread and make sure the LOAD capacitance?

(2) RM48L952: Crystal circuit recommendations? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--

Thanks & regards,
Jagadish.

Our design board as far as the RM48 and oscillator are concerned is the same as another production board we have that has been running successfully for a few years now.  Will double check calculations to confirm the LOAD, but certain that is not an issue.

Hi Dennis,

After comparing your broken code and working code, i could see only two differences

1. Reference clock divider for PLL1

In working code this divider is 8 and while in not working code it is 4, even though it is 4 should not be an issue because PLL1 max frequency is 200Mhz

2. Clock divider for the VCLKA3

In working code this divider is 3 while in broken code it is 1.

As we didn't enable the VCLK3A so there should not be any issue with this configuration too.

So the conclusion is these changes should not affect the behavior.

--

Thanks & regards,
Jagadish.

We replaced the RM48 chip on our board.  All was good but unfortunately, I was able to reproduce this issue.  The attached is again the system.c file.  The top is what caused the issue with the only real difference is setting the CLKTEST register. This was the only change I made between debugging sessions.

/** @fn void trimLPO(void)
*   @brief Initialize LPO trim values
*   
*	Load TRIM values from OTP if present else call customTrimLPO() function   
*
*/
/* SourceId : SYSTEM_SourceId_002 */
/* DesignId : SYSTEM_DesignId_002 */
/* Requirements : HL_SR468 */
void trimLPO(void)
{
    uint32 u32clocktestConfig;
    /* Save user clocktest register configuration */
    u32clocktestConfig = systemREG1->CLKTEST;
/* USER CODE BEGIN (4) */
/* USER CODE END */
    /*The TRM states OTP TRIM value should be stepped to avoid large changes in the HF LPO clock that would result in a LPOCLKMON fault. At issue is the TRM does not specify what the maximum step is so there is no metric to use for the SW implementation - the routine can temporarily disable the LPOCLKMON range check so the sudden change will not cause a fault.*/
    /* Disable clock range detection*/
    systemREG1->CLKTEST = (systemREG1->CLKTEST 
                        | (uint32)((uint32)0x1U << 24U))
                        & (uint32)(~((uint32)0x1U << 25U));
    
    /*SAFETYMCUSW 139 S MR:13.7 <APPROVED> "Hardware status bit read check" */
    if(LPO_TRIM_VALUE != 0xFFFFU)
    {

        systemREG1->LPOMONCTL  = (uint32)((uint32)1U << 24U)
                               | (uint32)((uint32)LPO_TRIM_VALUE);
    }
    else
    {
    
        customTrimLPO();
        
    }
    
    /* Restore the user clocktest register value configuration */
    systemREG1->CLKTEST = u32clocktestConfig;

/* USER CODE BEGIN (5) */
/* USER CODE END */

}
/** @fn customTrimLPO(void)
*   @brief custom function to initilize LPO trim values
*
*   This function initializes default LPO trim values if OTP value is 0XFFFF,
*   user can also write their own code to handle this case .
*
*/
void customTrimLPO(void)
{
    /* User can write logic to handle the case where LPO trim is set to 0xFFFFu */
/* USER CODE BEGIN (29) */
/* USER CODE END */
    
    /* Load default trimLPO value */
     systemREG1->LPOMONCTL   = (uint32)((uint32)1U << 24U)
                             | (uint32)((uint32)16U << 8U)
                             | (uint32)((uint32)16U);
                                
/* USER CODE BEGIN (30) */
/* USER CODE END */
}


/* SourceId : SYSTEM_SourceId_002 */
/* DesignId : SYSTEM_DesignId_002 */
/* Requirements : HL_SR468 */
void trimLPO(void)
{

/* USER CODE BEGIN (4) */
/* USER CODE END */

    /** @b Initialize Lpo: */
    /** Load TRIM values from OTP if present else load user defined values */
    /*SAFETYMCUSW 139 S MR:13.7 <APPROVED> "Hardware status bit read check" */
    if(LPO_TRIM_VALUE != 0xFFFFU)
    {

        systemREG1->LPOMONCTL  = (uint32)((uint32)1U << 24U)
                                | LPO_TRIM_VALUE;
    }
    else
    {

        systemREG1->LPOMONCTL   =  (uint32)((uint32)1U << 24U)
                                 | (uint32)((uint32)16U << 8U)
                                 | 16U;
    }

/* USER CODE BEGIN (5) */
/* USER CODE END */

}

Hi Dennis,

Good to hear that you solved the issue.

If possible can you please explain with more details, this might useful for future similar issues?

--

Thanks,
Jagadish.

The wrong resister was mounted for our oscillator and because of that the RM48 oscillators were being used.  When the above code was in place, per our understanding of the trimLPO(), the CLKTEST changes would disable these oscillators leaving our board 'dead'.   Temporary fixing our oscillator allowed us to reconnect with the RM48.

Appreciated for sharing all this.