The value is not stored in SRAM from the general-purpose register

[tommys]

Hello,

I am developing with LPC55S14(SDK Version: 2.8.2). When copying I2C data, the value is not reflected from the general-purpose registers to SRAM. There are two types, normal device and problem device, and the correct value is reflected in SRAM in the normal product. The procedure for checking the phenomenon is as follows.

(1) png1: Break at L781 of fsl_i2c.c and fill the copy destination SRAM with 0xFF.
(2) png2: Step to __aeabi_memcpy with assembler window. Then, the copy source data is copied to the general-purpose register(R4) by the LDM instruction.
(3) png3,4: R4 value is not stored in SRAM by STM instruction(normal product is no problem).

In png5, when R5 was filled with 0xFFFFFFFF before STM instruction as a trial, the value of R4 changed.

If this happens, what could be the cause? Is there a possibility of a device failure? Please let me know if there are any points to check.

I'm sorry, but I'm in a hurry to resolve it.

Best Regards,

[tommys]

Hello, There was progress on the situation. I was using the external clock input(clk_in) as the main clock(main_clk) through PLL0(pll0_clk:96MHz). However, when the internal oscillator (fro_hf:96MHz) was used instead of the external oscillator, the phenomenon that the SRAM value changed disappeared. Is there anything you can think of? Best Regards,

[Omar_Anguiano]

Hello

Hope you are well.
To test if this issue is caused by the external clock I suggest you execute the i2c example of the SDK(v2.10) in the latest version of MCUXpresso(v11.4) to see if the problem persists. I suggest you run the example with both external and internal oscillators.

I´m looking forward to hearing the results of this test to track the reason why this is happening.
If you have more questions do not hesitate to ask me.
Best regards,
Omar
 

[tommys]

Hello,

The problem was improved by using the spread spectrum function. Does this mean that noise was generated inside the MCU by using PLL0? Some MCUs are operating normally without using the spread spectrum function, but is it an individual difference of the MCU? Please let me know if there are any factors.

Best regards,

[Omar_Anguiano]

Hello

It is not likely that the noise was generated by the PLL since the internal clock did not have this issue. The most important factor for using the Spread Spectrum Function is the EMI.
It is important to ensure that the external clock is the suggested ratings of the device.

If you have more questions do not hesitate to ask me.
Best regards,
Omar
 

[tommys]

Hello,

Thank you for your prompt reply.
For additional information, we had a problem using PLL0 even with the internal clock.
We generate the clock setting code with MCUXpresso Config Tools. Then, as shown in the figure below, setting "PLL0 feedback clock divider by 2" to "Active" solves the problem, and setting it to "Bypassed" causes the problem. We presume that the problem was solved using the Spread Spectrum Function because "PLL0 feedback clock divider by 2" was changed to "Active".
(attached file:clock_config_active(OK).c、clock_config_bypassed(NG).c)

1. Does this difference in settings have anything to do with this problem?
2. Is it possible that the settings are outside the recommended range of MCU even when using MCUXpresso Config Tools?
3. Does "feedback divider" indicate MDIV? The generated source code appears to be related to PDIV.

Thank you for your cooperation.

Best regards,

[Omar_Anguiano]

Hello

I apologize for my delayed reply.
1. It could be the problem, this feedback clock divides is helpful to generate high frequencies in the PLL, if it is bypassed it is possible that the frequency is not locked correctly. The decision of using this divider is based on the frequency of the input clock.
 

2. This could be the case, I suggest you check the PLL value with the CLKOUT signal in the MCU.
 

3. This is more related to the Divide by M, in this figure you can see the block where this feedback divider is located.

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[tommys]

Hello,

Thank you for the reply.

1. It could be the problem, this feedback clock divides is helpful to generate high frequencies in the PLL, if it is bypassed it is possible that the frequency is not locked correctly. The decision of using this divider is based on the frequency of the input clock.
→Could you tell us the limitation of the input clock when using the frequency divider?

2. This could be the case, I suggest you check the PLL value with the CLKOUT signal in the MCU.
→In the Bypassed setting, the CLKOUT signal (96MHz) was not output. Are there any restrictions? A CLOCKOUT signal(16MHz) was output when the frequency was divided by the CLKOUT divider.

Best regards,

[Omar_Anguiano]

Hello
1. If the input clock frequency is too low; the feedback divider might help the PLL to reach the desired frequencies if the divide by M value is not enough.

2. The CLKOUT signal is to have a way to physically measure the clock signal of the PLL or any other clock. Enabling that output should not have an impact on the PLL functioning.

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[tommys]

Hello Omar,

Thank you for your reply. I undertand.

Best regards,