No USB-ISP Operation on i.MX RT 1052A

[mjbcswitzerland]

Hi All

I have a new board with the i.MX RT 1052 Rev. A part on it and its ISP mode over HS USB is not operating. With a USB analyser I can confirm that the low level HS USB operation is OK:

- the device successfully perform a high speed handshake and the host successfully sends a get device descriptor which the device also successfully acknowledges.
- The host then polls for the response but it only receives NAKs and never an answer.

This tells me the USB low level operation is correct but the boot loader's USB stack is not responding. I can't imagine how that could be the case at the moment since I never has an issue with USB ISP mode before (?).

Has anyone encountered such behavior or knows what could cause it?

Thanks in advance.

Regards

Mark

[melissa_hunter]

Hi Mark,

For the USB SDP issue, can you try putting external pullups on the LPUART1 signals (really just LPUART1_RX) and also making sure there is no activity on the line.

The ROM doesn't have specific mode, config, or fuse settings to boot into USB or UART SDP mode. Instead it does a detection phase where it will look for activity on the USB or UART. If it sees activity on the LPUART1_RX, even if it is just noise and not a full character, then the ROM will shut off the USB. 

As you've shown that the USB itself is working and working at HS, LPUART activity is probably the next thing to try and rule out.

Regards,

Melissa

[mjbcswitzerland]

Hello Melissa

You may be on to something - I did some tests and initially the USB would enumerate each time but when I put my finger on the connection to the LPUART1 RxD it wouldn't do so any more (USB layer worked but no answer to the device descriptor request).

I connected LPUART1 RxD to 0V and it worked a few times and then stopped.

Leaving it open it worked until I touched it with my finger again

Pulling LPUART1 RxD to 3V worked each time I tried so it looks like a pull-down is not reliable but a pull-up is.

Since this input is not connected in the design I assume that it is floating and the ROM loader doesn't enable a pull-up when it enables the LPUART Rx mode - if it reads '0' or possibly sees noise it suggests the USB is left enabled but its endpoints not.

I will add a pull-up to the next batch of boards to see whether it ensures reliable USB mode operation.

Thanks, regards

Mark

[FelipeGarcia]

Hi Mark,

We do not have these issues documented for A0 revision as you can see in our documentation, I will check with applications team to see if there is any more information we can provide. However, please keep in mind that these devices are deprecated by NXP and support may be limited.

Useful information for RT1050 - NXP Community

i.MXRT1050 Migration Guide

Chip Errata for the i.MX RT1050

Best regards,

Felipe

[mjbcswitzerland]

Hi Felipe

As you know it is virtually impossible to get any quantities of the B revision chips for the next few months or a year so we had to invest about $80k in this older stock and are now desperately trying to get something working for a week or so now - we are otherwise aware that the parts are depreciated but are still hoping that we will not be left stranded due to this fact after investing heavily based on the information that the errata work-aounds would be operational,

The other thread about power sequencing (the actual erratas being worked around) may be the most relevant since I assume that the USB and SWD difficulties are most probably a consequence of an issue there. I am adding new findings at that thread.

Regards

Mark

[mjbcswitzerland]

Hi All

Update on SWD issue:

This looks to be due to the fact that JTAG_MOD is not connected (underneath the BGA so no possibility to change it). Based on some information on this topic stating ""if JTAG function is not used at all you can just leave it unconnected" and the fact that we have an SWD header rather than JTAG this was left like this.

Experimenting with an i.MX RT 1052 EVK where this is pulled down with a 10k resistor, and removing the resistor, it is found that SWD mode also stops working, but works again when the resistor is added.

The conclusion is that it is therefore normal that SWD doesn't work, even if unexpected. This is not that serious as long as ISP is available for loading the code.

Regards

Mark

[mjbcswitzerland]

Hi All

Since it hasn't been possible to work with HS USB for the reasons noted above (although the HS USB low level is operating correctly as far as can be seen with a USB analyser) a LPUART connection has been attempted instead, which has proven to be more positive - the connection works and the processor details are displayed:

--------MCU device Register----------
OCOTP->UUID[31:00] = 0x625d7fab
OCOTP->UUID[63:32] = 0x331629d2
SRC->SBMR1 = 0x0
SRC->SBMR2 = 0x1000001
BMOD[1:0] = 2'b01 (Serial Downloader)
HAB status = Open
--------MCU Flashloader info-------
Current Version = K2.1.0
Target Version = T1.0.0
--------MCU device eFusemap--------
(0x450) BOOT_CFG0 = 0x0
(0x460) BOOT_CFG1 = 0x0
(0x470) BOOT_CFG2 = 0x0
BT_FUSE_SEL = 1'b0
When BMOD[1:0] = 2'b00 (Boot From Fuses), It means there is no application in boot device, MCU will enter serial downloader mode directly
When BMOD[1:0] = 2'b10 (Internal Boot), It means MCU will boot application according to both BOOT_CFGx pins and Fuse BOOT_CFGx
----------FlexRAM memory-----------
IOMUXC_GPR->GPR16 = 0x200003
FlexRAM configuration is from eFuse
OCOTP->MISC_CONF0[31:00] = 0x40
FlexRAM Partion =0000 - 128KB ITCM, 128KB DTCM, 256KB OCRAM
--------FlexSPI NOR memory--------
Page Size = --------
Sector Size = --------
Block Size = --------

Unfortunately the last command that is sent ("configure-memory") fails with the value 20106 (this error code is also seen when trying to erase the flash later).

Checking the FlexSPI interface it is seen that the Read SFDP register command is executed at this point and returns valid discovery parameters.

The part is a W25Q32JVSSIQS, and is selected in the Boot device Configuration of NXP MCU Boot Utility v3.1.0 as "Winbond_w25QxxxJV"

Since the command fails and the NOR Flash details are not displayed it looks like this part is not supported. Flash read is OK but when erase or programming is attempted it generates the error

The intermediate conclusion is that HS USB doesn't work (although the low level operation is fine) and LPUART does, but the QSPI flash on the board is not supported by the tool.

What would be the next thing to do to try to get the QSPI flash programmed? The first thing to be experimented is whether a USB device application operates in order to know whether the HS USB device issue is general for the HW or whether the USB ISP issue is restricted to the Boot Loader,

Regards

Mark

[FelipeGarcia]

Hi Mark,

Could you please clarify how exactly are you trying to communicate with USB HS ISP? I received a comment from apps team that confirmed that for RT1050 A0 and A1 silicon, the USB stack in ROM code had changed. So if you use the software matching A1 silicon, it is likely you will have issues to support A0.

Best regards,

Felipe

[mjbcswitzerland]

Felipe

The communication is with NXP-MCU BootUtility.

Since it wouldn't connect via HS USB I decided to see whether it would do so via LPUART, whereby I was very lucky that the pins used are connected and easily accessible.That worked and I could then load the code.

I loaded a USB-MSD bootloader (an application) and it worked normally on the HS USB that wasn't working in ISP mode.

What I noticed is that after loading and running this application I could switch to the ISP mode and the ISP operation was then possible on the same HS USB interface. This was not always the case but it did sometimes work, and when it didn't I used the LPUART mode again.

Therefore there is certainly something "unstable" with the HS USB ISP operation, whereby I have now worked with the application for a couple of days and it works with full reliability (always enumerates and never fails during operation).

What I noticed when the ISP HS USB fails is that there is a message (from the tool) asking to check that the ISP mode is correct and it states that ISP b110 is for USB and b010 is for LPUART (or maybe the other way around).
I assume that ISP bx10 are the Mode (1:0) pins to select the ISP mode but I have never heard of a bit to select between UART and USB mode and don't know whether this is an eFUSE setting or a pin. In any case it may be indicating that there is a pin to control this and its state was somehow changed when the application ran so that the ISP USB mode did work (a couple of times).

Therefore we have now managed to get the complete system up and running and so have a LPUART programming workaround if needed but the questions remain as to whether there is an unknown pin "floating" that switches between the two ISP modes, or whether this is related to the A revision.

Therefore, if there is additional information to help close this it would be very welcome.

Regards

Mark

[FelipeGarcia]

Hi Mark,

Thank you for the update, I am glad to hear that you finally were able to load your application using UART. I have sent this information internally to see if anything can come out of this latest update. I will keep you informed.

Best regards,

Felipe

[mjbcswitzerland]

Hi Felipe

Thanks again - in the meantime I have used the board for a few days with our boot-loader and application operating reliably.

I needed to reprogram the complete boot-loader yesterday to add the product's unique authentication settings (needing ISP mode) and it was interesting that the HS USB mode worked each time as long as our boot loader or application (both using the same HS USB interface) had been running before. It just behaves as initially reported when the ISP loader is started directly on power up.

Any explanation for this behavior would be welcomed.

Regards

Mark

[mjbcswitzerland]

Hi All

In addition the SWD interface is not working.

Above is the EVK SWD mode attach and below the attach attempt with this board (the SWD line stays high when data is expected to be read). All power supply voltages have their correct value and the processor has been released form reset - also the processor is seen accessing the external QSPI flash but neither ISP nor SWD modes are operating as normal.

This is potentially related to the power supply issues of the A version as discussed here:
https://community.nxp.com/t5/i-MX-RT/Large-current-surge-problem-during-power-sequencing-of-i-MX-RT/...

Regards

Mark