I am encountering a critical issue with the i.MX6 processor and hope to get help from the community. In a batch of circuit boards we produced, about 20% of the samples cause the processor to crash after accessing the DCP register. Below are the detailed background and information:
# Issue Descript
A batch of circuit boards was produced, and it was found that 20% of the samples exhibit the same defect.
When the code attempts to access the DCP register (address 0x02284000), the processor completely crashes, and even the JTAG debugger can no longer access the core. JTAG reports the error:
“Error: data abort at 0x02284000, dfsr = 0x00000008”.
Once this error occurs, the processor cannot resume execution (even if "c" is entered to continue).
Boards No. 3 and No. 6 are defective. It was temporarily observed that the VDD_SNVS_IN voltage is slightly higher on these boards compared to others.
Error data abortError data abort
can accesscan access# Hardware Environment
I am unsure if there are differences in the circuit voltage point design, so I measured the voltage differences between the faulty boards and the others.
- Processor: i.MX6ULL (MCIMX6Y2)
- Faulty Board Numbers: No. 3 and No. 5 (failure rate ~20%)
- Normal Board Numbers: The remaining 80% of boards
# Code Reproducti
The following code is used to reproduce the issue. If the DCP access part is uncommented, the LED stops blinking (processor crashes):
Manually accessing DCP via JTAG also triggers the error:
>>> set $R = 0x2284000
>>> p/x *$R #include "MCIMX6Y2.h"
#include "fsl_iomuxc.h"
#include "pad_config.h"
#define LED_PAD_CONFIG_DATA 0x13008
int main()
{
CCM_CCGR1_CG13(0x3);
CCM_CCGR3_CG6(0x3);
IOMUXC_SetPinMux(RGB_RED_LED_IOMUXC,0);
IOMUXC_SetPinConfig(RGB_RED_LED_IOMUXC, LED_PAD_CONFIG_DATA);
GPIO1->GDIR |= (1<<4);
GPIO1->DR |= (1<<4);
while(1)
{
GPIO1->DR &= ~(1<<4); // led on
delay(0xFFFFF);
GPIO1->DR |= (1<<4); // led off
delay(0xFFFFF);
#if 0 // Turn on the code, MCU will be crash
int *ptr = 0x2284000; // This is DCP address
UART1_PrintHex32(*(ptr));
#endif
}
return 0;
}# Other Finding
- Normal boards return 0x10000281 when accessing 0x2284000 (as expected).
- According to the manual IMX6ULLRM.pdf, we tested all other peripheral registers, and none triggered a data abort. The issue is limited to the DCP region.
well (ADC1_HC0)
set $R = 0x2198000
p/x *$R
well (AIPSTZ1_MPR)
set $R = 0x207C000
p/x *$R
......
well (TEMPMON_TEMPSENSE0)
set $R = 0x20C8180
p/x *$R
well (TSC_BASIC_SETTING)
set $R = 0x2040000
p/x *$RRequest Help
- Relationship between DCP and the clock tree: Which clocks does the DCP module depend on? Is any special clock configuration required?
- Hardware design defect: Could the slightly higher VDD_SNVS_IN voltage be the cause? Are there other voltages or signals that need to be checked?
- Software configuration: Are there any special DCP initialization steps or protection mechanisms?
- JTAG debugging: Is there a way to restore JTAG connection after a DCP access failure?
Have you followed the need in our guide:
1. Timing satisfied, 2 MS.
2. Using coin cell battery power supply, still crashes after accessing the DCP registers.
1. IMX6ULLIEC.pdf Table 10 Operating Ranges描述VDD_SNVS_IN工作范围在2.8～3.6V，
典型3.0V.
2. 但是手册并未说明，提前多长时间？
原理图设计上，VDD_SNVS_IN 的确比VDD_HIGH_IN和VDD_SOC_IN 先上电。
示波器观察的确如此，大约提前1ms，是否足够？
是否因上电时序引起状态不一致，下面的实验很好验证。
电源树
3. 的确总共做了10套板子，2块存在相同故障。
4. 板子跑uboot+linux卡死。
uboot/arch/arm/mach-imx/mx6/soc.c
试图从DCP模块获取随机数作为序列号时，SOC Crash。
于是尝试编写裸机LED程序，在代码里读写DCP寄存器，同样 Crash
int arch_misc_init(void)
{
if (IS_ENABLED(CONFIG_FSL_DCP_RNG)) {
struct udevice *dev;
int ret;
ret = uclass_get_device_by_driver(UCLASS_RNG, DM_DRIVER_GET(dcp_rng), &dev);
if (ret)
printf("Failed to initialize dcp rng: %d\n", ret);
}
setup_serial_number();
return 0;
}接下来尝试：
1. 将所有板子时序一同测试时序是否一致，测试VDD_SNVS_IN究竟有多少抖动。
2. 板子接入纽扣电池3.0V，保证VDD_SNVS_IN一定处于最先上电，避免时序影响。
完成上述之后再回帖
VDD_SNVS_IN This power supply is generally required to be 3.0V, and when designing the board, this power supply needs to be the first one to be output out to the CPU's
P12 pin (VDD_SNVS_IN pin). You are also meeting the requirement here here.
And you can see it in the manual.
If VDD_SNVS_IN is directly supplied by a
coin cell, a schottky diode is required between VDD_HIGH_IN and VDD_SNVS_IN
Do all your designs here meet the requirements? Also, you've made a total of 10 boards here, and two of them don't work well?
What software are you running on your board?