IMX1011 Custom Board Bringup No Breakpoint in Main()

[functional_des]

Hi There,

We have a custom IMX1011 board that is fairly simple, and which is based in large part on an existing functional IMX1064 design, and the IMX 1010 EVK. However it is not working with a basic Blinky sketch, and I want to see if anything that I am seeing makes sense to anyone out here. 

What Works: I can sort-of run the standard Blinky example if I link application to ram (evkmimxrt1010_iled_blinky)

• I get the first breakpoint in main
• I can step through the code a few lines and short functions at a time
• However if I let the code run for too long (well under 1s) without it hitting another breakpoint, then it will crash out and stop running. 

  • SysTick_Handler will sometimes trigger but usually it crashes before hitting this

  • If I replace SysTick delays and disable the ISR with a for loop running  __asm("NOP"); then it does better with fewer loops : 20 loops as a delay is fine, 2000 gets unstable. It still only works with me stepping through the code, it won't run freely
• This is with the Boot fuse pins to 0,0 or to Boot_Mode[1,0] = FlexSPI Boot
• When it does deadbeef out, I then see chatter on the flash chip that looks like a fresh POR reboot (if the Boot config is set for it). 

Other notes and things I've tried: 

• Not linking to RAM, The Blinky will hit the reset handler sometimes, but never main, and then it hard-faults
  • This is with Boot mode in all 3 main configs
• Scoping the Flash chip I see chatter on the lines when loading code, and on POR
  • For a brief period it did seem to chatter on the flash lines during power up, but that is gone now
  • Voltage levels look pretty good on all lines, though the RESET line on the Flash chip seems pretty active. I don't know how active it stood be
• We have a USB port hooked up to the native USB pins and that will instantiate as a USB device visible in the device manager when connected to my computer.  
  • This will stay instantiated until i do a reset command in j-link, where it will drop out. This makes sense
  • I mention this test because it indicates that the clocks are probably working fine if it can instantiate as a USB device
• I have checked the oscillators (24MHz and 32KHz) and they look good overall, though I haven't really dug into them. Given the above notes on the USB though, I think they're OK. That said, the intermittency issue when debugging does sort of point to a clock problem
• SDK is the MIMXRT1011xxxxx, and the processor has been set up to match the variant we are using. 
• Running examples on an EVK is not an issue

Thanks in advance for any help. 

[jingpan]

Hi @functional_des ,

Can you share the schematic?

You said there is a USB port and if connect to computer, it can be enumerated? Please set the chip to serial download mode and try to connect to boot ROM, using MCUBootUtility. If it can connect successfully, you can test the flash erase/read/write.

Regards,

Jing

[functional_des]

Thank you @jingpan. Attached is the schematic, as you can see it is fairly simple as this is a test breakout board. 

IMPORTANT NOTE : I Discovered that the NVCC bus was not connected to anything. I shorted it to the 3V3 bus, which has helped the drive strength, but I am still seeing the same issues. 

A few other notes that are perhaps useful: 

• It often takes a number of tries to get a good J-link connection and I often need to repower the device to get a good connection to it
• I am able to run my example code on an EVK without issue
• When I measure the voltage rise (see attached) it takes ~2.4ms to start the 3V3 line rising, and ~13ms to do the total rise/power up
• I am now able to run for a few cycles before death if I use a NOP based delay loop
  • It is pretty variable and depends in large part on the cycle time. In general it can survive from anywhere from 30ms to 400ms before it stops cycling 
  • If I use the native SysTick configuration scheme I seldom see any successful triggers, though sometimes it will trigger a cycle or two
• When the NOP-based looping ends, I can sometimes pause the debugger and land in the hard fault handler. When I do that, I get the attached result

Running MCUBoot utility over the USB port, I see some interesting behavior but no success: 

• I can connect to the device, but the USB device leaves soon after starting the process
• I was successful in connecting to my EVK in serial mode. In boot mode it didn't even show up as a usb device - I assume this is expected
  • interestingly my device shows up as a USB device whether the Boot pins are set to serial or boot mode, or both low. This is with the boot pins getting pulled up to either 3V3 or 3V3_SNVS. Perhaps this is indicating something? 

Here is the log output from the boot utility : 

'Connect to xxx' button is clicked

Executing \xxx\NXP-MCUBootUtility-master\tools\sdphost\win\sdphost -t 50000 -u 0x1FC9,0x0145 -j -- error-status

Executing \xxx\NXP-MCUBootUtility-master\tools\sdphost\win\sdphost -t 50000 -u 0x1FC9,0x0145 -j -- error-status

Executing \xxx\NXP-MCUBootUtility-master\tools\sdphost\win\sdphost -t 50000 -u 0x1FC9,0x0145 -j -- write-file 538990592 \xxx\NXP-MCUBootUtility-master\src\targets\MIMXRT1011\ivt_flashloader.bin

Executing \xxx\NXP-MCUBootUtility-master\tools\sdphost\win\sdphost -t 50000 -u 0x1FC9,0x0145 -j -- jump-address 538990592

Thanks for the help

[jingpan]

Hi @functional_des ,

If serial download mode, boot ROM will take control. Boot pin is 00 means boot from fuse. But if  BT_FUSE_SEL = 0, indicating that the boot device (for example, flash) was not programmed yet, the boot flow jumps directly to the Serial Downloader. In serial download mode, USB HID is enabled. So, you can use sdphost to connect boot ROM.

Please check

1 VDD_SOC_IN_x voltage;

2 POR_B status, is it stable?

3. Is RTC stable?

4. Is 3V3 bus the P3v3?

5. It seems boot ROM can work. Please disconnect debug port and use sdphost to send those command one by one. Will it reset or dead?

Regards,

Jing

[functional_des]

Thanks @jingpan 

1 VDD_SOC_IN_x voltage; : This is stable at 3.3V and is shorted to our P3V3

2 POR_B status, is it stable? This is stable at 3.3V

3. Is RTC stable? The RTC seems to be stable at 32.5->32.9 KHz reported by my scope

4. Is 3V3 bus the P3v3? Yes, P3V3 is our 3V3 bus

5. It seems boot ROM can work. Please disconnect debug port and use sdphost to send those command one by one. Will it reset or dead? I will try this tomorrow and let you know how it looks

[jingpan]

Hi @functional_des ,

VDD_SOC_IN_x is from internal DCDC, the voltage should be around 1.1V. Please check again.

Please also check XTAL signal.

Regards,

Jing

[functional_des · Accepted solution]

Hi @jingpan It turns out we just had some sort of strange hardware issue. Soldering a new board fixed the issue. Thank you for the help