imx6ul efuse boot not working

[dbjohnson]

We have designed and built our own twin IMX6UL application PCBs.  

Using a bare-metal application of ours to deal with all non-volatile programming on this board, we have programmed serial NOR flash memory with a 2nd stage boot loader, main application software(ThreadX based), data sets, etc.  

All of this works fine when boot is controlled Internal mode by GPIO pin settings on our breadboard PCBs.   The iMX6ULs boot as expected, reading from ecSPI4 (CCS0), handing off to 2nd stage boot loader, loading main app and launching... both processors.

Our release PCB design does not have the GPIO pin connects, so we must boot by eFuse.  WE have "dress rehearsed" this on our breadboards with discouraging resutls:   Of four iMX6UL's that had been booting successfully from GPIO pin override, but then had the eFuse's set:
   1)  One of the four iMX6's will boot properly.   The software loads in through the ecSPI4 channel just fine.

   2)  Three of the four IMX6's fail to boot.  Chip select asserts but no communications take place to the NOR flash.

When we inspect by JTAG the eFUSE configuration for all four processors after power up (by JTAG connect), we see what we programmed (attached):

OCOTP_CFG4:    0x0B000003   =  BootCFG4 : 0 : BootCFG2 : BootCFG1  for using ecSPI4  with CCS 0 to Serial ROM

OCOTP_CFG5:    0x00000010    =  BT_FUSE_SEL  (at bit 4)

Note:  Don't know if related:   On the three that fail to boot in eFUSE,  corrupted values of fuses appear in the shadow registers when we do re-load-to-Shadow operations.  This is not the case on the one processor that is successfully booting.  The corruption often had bit7 of each eFuse byte reporting as "1".    However, after power up when the ROM boot loader loads the shadow registers, inspection over JTAG always reports the values we expect (exactly what we believe the fuses should be).

Can you confirm we have proper values set the _CFG4 and _CFG5 eFuse words?  

Why is this problem "marginal"...   works on one, but not the other three iMX6UL?

Again, before burning these eFuses, all four processors were successfully booting from serial NOR flash using GPIO override. 

Thanks for any help you can provide

[dbjohnson]

Date code being used in all produced circuit boards thus far.

[dbjohnson]

Our problem with fuses on iMX6UL persists.   Per my last posting, I was led to believe that if we use a procedure that disconnects JTAG from our circuit board, enters a programmed delay, and then executes the fuse-writing command, we would escape evident damage to the fuse-reading circuits that is resulting from writing fuses. 

With 12 iMX6UL's submitted to this process (JTAG-free fuse burning) we are getting a fall out rate that is comparable with the experience of nearly 30 iMX6ULs that had fuses burned while software ran under active JTAG connection.

The steps we follow to set up boot from fuse configuration:
     Operation #1:   Blow 5 fuse-bits in  OCOTP_CFG4 for desired boot configuration

     Operation #2:   Check the 5 fuses are burned after re-powering

     Operation #3:   Command a re-load of OCOTP_ shadows and check them

     Operation #4:   Blow the BOOT_FUSE_SEL (bit 2) of OCOTP_CFG5

The statistics:

     20% of iMX's fail Operation #1

           - Operation #2 reveals this.  

           - Operation #3 informs us that there are fuse misreads at the same bit sites that a fuse failed to burn,

      65%  of iMX's reveal issues in Operation #3 , that is fuse misreads (0 --> 1)  when re-loading shadows

       -  If the fuse-reader damage does affect one of the 5 bits we burn, (Operation #1 passed) then there is still a chance we can boot the article from its fuses.  

       -  In the 20% that fail Operation#1, the fuse reader misreads (byte wise) Bit 1. 

    ? %  iMX's will fail Operation #4 because fuse reader damage affects either

          1)  Bit 4,  so that BOOT_FUSE_SEL in OCOTP_CFG5 will not be burnable

          2)  Bit 2   so that the LOCK  Write-Prevent bit will be misread and disallow furthre fuse writes

We are now at a loss to cite any cause other than iMX6UL defect.   Our production runs all have consumed IMX6UL's with same date code.   (we don't have other date codes to compare).

This is critical to our product release circuit boards that can only boot from fuse configuration.  Please advise

[igorpadykov]

Hi David

so is fuse write/read working fine with procedure described on

Q&A: How to program i.MX6 eFUSE? 

with official demo image

https://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_MX6QDLSOLOX&appType=license&location=nullhttps://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_MX6UL7D&appType=license&location=null 

If issue persists only with custom uboot&jtag may be recommended to proceed with

 Professional Services for extended support

NXP Professional Services|NXP 

Best regards
igor

[dbjohnson]

We are now moving ahead to blow eFUSEs in our production PCBs.  Up till now, have done this successfully on bread board systems.   A totally new problem has emerged in this production lot.   We cannot get the right value to burn for BOOTCFG4 on half of our iMX6ULs.   (3 of 6 tested so far,   fail in identical manner). 

The malfunction:   We burn BOOTCFG4 = 0x0B, but find upon reset that BOOTCFG4 is 0x09. 

Bit 1 is failing to burn.  Full description below. 

Could this be component problem?? 

See 

[igorpadykov]

Hi David

>Could this be component problem?

in general yes. Suggest to check board hardware using
Hardware Development Guide for the i.MX 6UltraLite Applications Processor
https://www.nxp.com/docs/en/user-guide/IMX6ULHDG.pdf

and try chips from other date codes. Contact nxp local marketing office for

FA procedure.

Also suggest to use programming from uboot

https://community.nxp.com/docs/DOC-95458 

Check that during programming no other external devices (like jtag, e.t.c.)

were connected to board. Recommended to check power-up sequence.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dbjohnson]

Igor, 

"check that during programming no other external devices (like jtag, e.t.c.)"

   Are you stating that fuse-burning cannot be done with JTAG deployed firmware?

We are experiencing that 25-30% of our iMX's are consistently and repeatably failing to blow one of the 5 configuration fuses (0 --> 1) we set in OCOTP_CFG4.   Indeed the utility that I am using to blow fuses is deployed over JTAG.   

In our production PCB design, our only means to boot the iMX6UL is fuses.  I'm not sure there's any choice to get f/w into the processor (that will burn fuses) other than JTAG.  

Please confirm that live-JTAG could be the cause of these issues.

 Thanks

[igorpadykov]

David

to narrow down issue why " We burn BOOTCFG4 = 0x0B, but find upon reset that BOOTCFG4 is 0x09. 

Bit 1 is failing to burn. ", may be suggested to try burning not with jtag but with uboot.

Programming from uboot

Q&A: How to program i.MX6 eFUSE? 

Using jtag please check that power-up sequence was not violated:

not allowed to apply any external signals to unpowered processor until

it fully powers up. From sect.4.2.1 Power-up sequence i.MX6UL Datasheet
http://www.nxp.com/docs/en/data-sheet/IMX6ULCEC.pdf

"NOTE
Need to ensure that there is no back voltage (leakage) from any supply on
the board"

Best regards
igor

[dbjohnson]

More about the faulty behavior:

My assessment of the problem-   when we execute the procedure to burn one or more fuses with our bare-metal burner program running on JTAG,  the fuse-read structure used by  OCOTP software method is being damaged.  This happens on a byte wide basis-- so bytes across all fuse banks will present a common fault on specific bits.  Once the fuse reader has this fault,  I suspect it fools the burn operation for that bit into behaving as if the fuse is already burned.   

Thankfully, at power on reset of the iMX6UL, a different scheme interprets the fuses, one that accurately captures the true fuse states to the OCOTP shadows and the SRC_SBMRI.  So on many IMX's the fuse reads are corrupted, but we indeed did burn the correct fuses and the they will boot from eFUSE  (60%) 

uboot "out of reach":

As our only boot option on this production board is eFUSE, we'd have to have a way to get a uboot app loaded and running free of eFUSE & JTAG.   Serial boot the only possibility.. but wasn't provided for in our PCB design.  Not to say "impossible", but this would be a tricky hardware effort (aside from the software effort entialed)

JTAG  may be the problem !    Doing JTAG w/o JTAG connection:

                {  Performed on 6 imx6ul's in a row.  Desired fuses burned.  No post-signs of efuse-reader damage }

   -   JTAG in our bare metal efuse-burn firmware  (IAR ARMWB) to virgin IMX^UL

    -   Run to immediate break point

   -    Shut down debug session to release the firmware off the break point.  

    -   F/W  executes a 5 sec delay, more than enough time to disengage a pogo pin JTAG physical connect

    -   F/W then completes task of burning fuse .. with imx free of JTAG interactions.

[dbjohnson]

Thanks!   

 I looked at those SRC regs after realizing that my failing IMX6's had EIM I/O's enabled.  The problem had to be unintended boot configuration.  That's when I spotted the mistake in BOOT_CFG1, which needs to be 0x30,  not 0x03!

So the reported fuse configuration in my first post:

OCOTP_CFG4:    0x0B000003   =  BootCFG4 : 0 : BootCFG2 : BootCFG1  for using ecSPI4  with CCS 0 to Serial ROM

       needs to be:  0x0B000030

Lots of eyes here missed that, as perhaps you did too.

And lucky me!   I can burn 0x0B000033 to OCOTP_CFG4.   The lowest 4 bits are "reserved", and to my delight are not factored by the RBL. So I've got all the processors booting ecSPI4/SS0 - Serial NOR from fuses now.  

I am still puzzled about the erratic variance chip to chip on software commanded read of fuses. Most of IMX6ULs generate bit errors on READ_FUSE_DATA or just re-loading shadows, yet two of my IMX6ULs read fuses correctly on software command.  Since the shadows are accurate after power-on-reset occurs, most users probably can live with that.  

[igorpadykov]

Hi David

after boot fail one can attach jtag debugger and check SRC_SBMR1,2 registers for

verifying boot configuration, compare it with good board.

Also recommended to use nxp uboot from https://source.codeaurora.org/ 

repository:

uboot-imx - i.MX U-Boot 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------