RT1064 bricked?

[kl]

Hi,

We have developed a custom board for the RT1064, which worked fine until yesterday. Nor the MCU seems bricked. The last flashed application firmware runs for a second, an in this period it transmits the initialization information on UART5. Then the execution halts. It might be a bug in the firmware, but I do not think so.

I cannot connect to the MCU through the SWD debug interface using a J-link programmer. (Boot mode set to "10" = internal boot)

If I change the boot mode to "01" Serial Downloader the application software does not start as expected. But the USB device does not enumerate on the PC. I have no used/tested the USB port in the application firmware yet, but it should be wired correctly.

I have also tried to connect the UART1 to the evaluation board "MIMSRT1064" by removing the jumpers J45-J50 (And J36 to be sure that I am not communication with the MCU on the eval board.) Connecting the J45-1, J46-1 and J44-2 to my target MCUs UART1 and POR pins. Using the Link Server programming tools with MCUXpresso did not work either.

Then I tried to verify which programming interface the evaluation board actually used if I put it into Serial Downloader mode. And I was surprised that this mode actually used the SWD interface for programming. That was proved by removing jumper J47 and J48 (The rest of the jumpers mounted as at delivery) which disabled the programming with Link Server. I was expected that it was J45 and J46 I had to remove to disable Serial Downloading.

Two questions:

* Is my custom board bricked? Can I do any further attempts to wake it up again? Or should I trash it?

* Why is the evaluation board acting as observed in Serial Downloading mode?

Bonus information: By using the evaluation board we now and then has to put it into Serial Downloading mode because the "normal" way is failing. We cannot find out why, but it is annoying and we fear that it is actually the problem we experience with our custom board. Could it be?

Regards

Kasper

[kerryzhou]

Hi kl,

   If your own board enter the serial download mode, whether you can use the MCUBootUtility to connect your board or not?

   Or, when you enter the serial download mode, can you use the JLINK to connect your chip with the jlink commander, then you can erase your external debugger, and set to the internal boot again.

   Your issue should be caused by the external memory firmware is not good. You can erase all the external memory, then download it again.

   Please note, when you use the USB HID in the serial download mode, set to the serial download mode, make sure the LPUART1_RX is high and no wave input, otherwise it will enter the UART serial download mode,  then power on, then you should can find the USB HID.

 Wish it helps you!

If you still have questions about it, please kindly let me know.

Best Regards,

Kerry

[kl]

Hi, 

Just found out that the embedded DC/DC converter turns off. I have no code allowing the MCU to entering sleep mode. What can bring the MCU into sleep mode?

Unfortunately we have not routed testpoints to the output pins PMIC_STBY_REQ and PMIC_ON_REQ, so I cannot investigate this further.

Even if I set it up to serial downloader mode, the DC/DC converter is off. ???  (UART1_RX is tied to 3V3 by the way, and I have no external program flash.)

Our design looks like this:

[kerryzhou]

Hi kl,

   Do you add the external DCDC component?

    This is the recommended hardware circuit:

From your description, this should still your hardware issues.

Do you have the MIMXRT1064-EVK board, whether that board have issues on your side or not?

Best Regards,

Kerry

[kl]

Hi  Kerry,

Yes, the DCDC component are mounted as designed in the snippet I attached.

In the RM I re-read section "18.6.1 Turn on DCDC", it specifies "PMIC_ON_REQ = 1" as part of the start-up sequence. But in the datasheet PMIC_ON_REQ (Pin L7) is specified default as an output. Should I do anything on this pin (HW or SW) to avoid sleep mode? In the config tool it is specified as an input (when SNVS_PMIC_ON_REQ is routed to PMIC_ON_REQ), and cannot be changed to output. What shall I believe? If I configure the PMIC_ON_REQ (and only if), the config tool adds this line to the pin_mux-file: "CLOCK_EnableClock(kCLOCK_IomuxcSnvs);", even though that it is configured as default. Should I take special notice here?

On the other hand PMIC_STBY_REQ is defines as an input???

What do you recommend for the HW design, and haw should I configure it in the config tool?

Regards

Kasper  

[jingpan]

Hi kl,

PMIC_ON_REQ pin and PMIC_STBY_REQ pin are both output signal by default. And when power on, they are in their default function. You needn't change them or config them.

Do you mean if you set the board in internal boot mode, the system will power down after execute user's application? Can it run in serial downloader mode? If it can, please use MCUBootUtility or other tool to erase external flash first.

Regards,

Jing

[kl]

Hi Jing

In Serial Downloader mode the DCDC converter only runs for 100ms, then the system enters sleep mode. A reset will restart the sequence. But the j-link debugger cannot connect to the device (Using J-Flash application). It tries to reset and connect a number of times with no luck. So I think that the Serial Downloader mode is unavailable. I feared that we have a HW design bug causing this, but it should be OK.

I have not tried the MCUBootUtility (I do not know how to install it). But my custom board has no working USB interface, and UART1 is not very easy to access as it is used to other purpose. I believe that J-Flash is capable to do the same.

Kasper

[jingpan]

Hi Kasper,

I can't find any obvious mistake on your diagram. But you say that the problem is still there in serial downloader mode, it should also not caused by your software. In serial downloader mode, cpu stay in ROM bootloader.

Please observe these pin.

1. VDD_SOC_INx. Can it arrive 1.1v? What waveform can you see? 

2. Compare PSWITCH with DCDC_In_1. Is 1ms delay enough?

3.  POR

This board can work at first, but I still think it can be a hardware problem. You canceled a lot of cap on VDD_SOC_INx and other power pins. The cap on VDD_SNVS_CAP is not the recommend value. They may not fatal error, but will cause system unstable.

If it is possible, you can make a new board, start from minimum system. And compare with current board.

Regards,

Jing

[kl]

Hi,

Thanks for your review. The SNVS capacitor is clearly a mistake. It changed a little. We have the same number of capacitors on 3v3 and on 1v1, just located out of the schematic snippet. I have measured the voltages during power up.  I have measured the start up time on the 3v3 and the values for the RC delay should be within the requirements. 

I can restart the DCDC converter by toggling the PSWITCH input. But not the POR input.

I have a single time last week been able to se the MCU start up, and I could connect with the j-link debugger. Unfortunately I did not erase the flash as the first thing.

I have several 'virgin' boards, but it takes some time to bring it up, and I want to take some countermeasures to prevent it being bricked.

Any ideas?

[kl]

Hi.

I just found out that the TEST_MODE pin is unconnected. The datasheet specifies that this pin must be grounded, and has an internal pull-up. 

Could this be related to out problems?

Kasper

[jingpan]

Hi,

In hardware_development_guide_for_the_mimxrt1050/mimxrt1060_processor, it also says the TEST_MODE input is internally connected to an on-chip pull-down device. You may either float this signal or tie it to GND. There is no word say it is internal pull-up. I think this is not the problem.

Your board can work a short time last week, so could it be a welding problem?

Regards,

Jing

[kl]

One more error in the documentation i believe. In the datasheet Table 85, I found following:

Unfortunately I cannot measure it. On the Evaluation board it is grounded, and it is un-connected on our design.

Let the case rest here, I do not think you can help us. I will post a follow up if I solve it.

Kasper

[kl]

It appears that the start up of an auxiliary power supply created some issues on the 3v3. We still do not understand why the RT1064 shuts down. But it will be investigated, but later . . .