IWR6843: xwr68xx_mmw_demo.bin or xwr68xx_mmw_demo-signed.bin stopped working

Hello Shareef, 
Since day one (several years ago), they (SW)  implemented an active reset at power up, they release reset when the flash loading procedure is done (about 17sec after power up). This still is in place, the product inhouse built code still works fine with this but now the premade binary images from TI no longer work.  But we will certainly try this to see if resolves.

The datasheet does not provide a minimum NRESET time, any guidance?

More information,
Apparently we never change SOP mode, it is default always 001.  We don't use QSPI, we load volatile R4F flash file at every bootup via UART only.  Is SOP always 001 correct for this operation mode?  Is toggle reset after UART R4F load required for this flow?

The failure condition are chasing currently is with IWR6843AQGABL
But we must support also IWR6843AQSABL
(we need both because of the supply chain pandemic, we have unique PCBA part numbers for each)
Previous PCBA's both versions seemingly no issues.for production uart file load and for factory testing uart load of TI binary files.
Most recent PCBA versions, so far we have only tested "G" version, production flash load works fine, factory line TI binary factory flash load always timeouts.
Can you kindly describe the proper flow including authentication and RESET handling for UART flash updating?

also can someone please answer previous question about SOP = 001 always is okay?

Hello Chethan,
If you looked at my earlier post "We don't use QSPI, we load volatile R4F flash file at every bootup via UART "
1)) We only write file to volatile  IWR memory., Is SOP = 001 ALWAYS okay, no need to change, correct?  

Was there any changes made to recent PCBA or changes in the flashing procedure?
Density => Some power tree changes BUT IWR6843 is held in reset safely until long after all power rails are stable, then reset is deasserted.

Is there a difference between the production UART file load vs factory UART load of binary files?
Only difference is production UART load is shorter time to load file, production OS performs iwrflasher at bootup at abput 15 secs (long after rails stable and NRESET released)  NRESET is released, UART loads IWR6843, this always works. we have no explicit NRESET toggle after UART load, and this seems to work fine.

Factory UART load, PCBA sits much longer time, could be minute or more easily (with NRESET asserted), then operator send command to load IWR via UART with TI premade binaries, same iwrflasher code, separate binary used for GP vs. HS.  NRESET is released much later in time, UART loads IWR6843, we have no explicit NRESET toggle after UART load, is this okay?

Is there any hardware difference between the two flows?
NO, only the timing mentioned above.

Hello Shawan,

   Give us couple of days to check and get back to you. 

Thanks and regards,

CHETHAN KUMAR Y.B.

Apparently I was wrong about programming IWR with UART, programming is actually done via SPI, (in both working case and non-working case as previously described) so in this case always SOP = 001 is okay, correct?  
Kindly please advise recommendation on NRESET, pulse before and or after, and what is minimum pulse?

Hello Shawan,

     Yes, programming the IWR device through the default functional mode (SOP = 001) is supported only through the SPI interface. 

After the SOP configuration, NRESET need to be applied to register boot mode by the device. 2-3msec of low time is acceptable, assuming that power supplies are stable by then. If the power supplies are not stable allow time required to stabilize within the datasheet limits. This time may vary depending upon the design, number of decaps, filters etc. 

Thanks and regards,

CHETHAN KUMAR Y.B.

Hello Chethan,
I confirmed that no SOP changes after NRESET is released.  Still same problem.  Production flash image (made by Density) loads and runs, premade TI image after loading we get timeout error.  Latest batch of new PCBA's all manifest error, previous version of PCBA"s only some manifest error.

GP IWR device we load xwr68xx_mmw_demo.bin  (unsigned file)
No errors at SPI loading
then run calibrate command and get error message
ERROR: Caught exception Timeout expired

Also I forgot to mention, we tried to change only our product OS, only change file to load, we use Density flash file works, we use TI xwr68xx_mmw_demo.bin , receive Timeout,

Chethan, one more question to add to the previous 2 posts, during SPI flash programming ,does it matter if NRESET is active or inactive? I cannot find this specified in the documentation, or any explicit NRESET toggles before or after either.

Hello, can anyone chime in, still having failures only when loading premade  TI demo bin files via SPI.  
It seems the IWR6843 is unresponsive after the load although no indications at all of SPI loading problems.
Any suggestions to help figure out why the IWR is unresponsize in this case?

Hello Shawn,

     Please refer to above timing diagram (Red arrow), NRESET if it's held low device would be in reset condition, for normal mode of operation NRESET should be high.  

Thanks and regards,

CHETHAN KUMAR Y.B. 

Hello Shwan,

     I have requested our software team to review your query. 

Thanks and regards,

CHETHAN KUMAR Y.B.

Questions for SW team:
Are there functional HW differences between "Q"(non-functional) and "B" (functional) variants?
Early testing shows removing line to restore calibration data from QSPI (we never have had QSPI on our boards) seems to resolve the previously failing "B" variants but the old boards we have around "Q" don't fail with this restore calibration data from QSPI line, does  this make sense?

Hi Shawn,

My understanding is that there is some HW differences between the two variants in order to enable some of the SW features which are exclusive to the Functional Safety variants (Perhaps HW team can comment more here). However, I do not think that the differences should make any impact on this the behavior for the QSPI driver. However, in this case, isn't the correct solution clearly to remove these calibration restores, since they are attempting to read a QSPI line which does not exist?

Best Regards,
Alec

Thanks Alec,
More info today
03.04.00.03 old SDK runs fine on our oldest boards (i believe all are QG, non-functional variant)
BUT this code fails on all of our new boards, ( (i believe all BG, functional variant)
(FYI, this code does not seem to have QSPI memory call)

03.05.00.04 SDK with calibration read from the eeprom disabled runs ok on old boards "Q" and new boards "B"

BUT, We need to understand root cause, is it possible old SDK is expected to fail on new "B" functional variant?

Hello Shawn,

Thank you for your patience, this question made it's way to our team now.

Just to confirm, are you saying that you are loading a premade image from TI (xwr68xx_mmw_demo.bin) via SPI and the image is loading correctly but then it is not behaving correctly after device is placed in functional mode and NRESET is pressed?

1. Where did you get the TI image xwr68xx_mmw_demo.bin?

2. How are you confirming that the image loaded correctly?

Thank you,

Angie

I believe we used premade images from TI devkit package i believe for awhile
03.04.00.03 old SDK runs fine on our oldest boards (i believe all are QG, non-functional variant)

All of a sudden on new General versions of the chip which we notice are BG (functional variant) we fail.  We believe the SPI loading is working, no SPI loading errors of any kind, after loading we try the calibrate command and we Timeout.  We don't yet know why??  There is no QSPI call in this code.

SW team has tried the new SDK and inhouse build the .bin  file and IF they comment out the QSPI restore line (which we don't have) seems to work for all our boards, QG and BG variants.)  We understand why commenting that line outs works successfully, but need help expaling the old SDK failure on new boards.

Hi Shawn,

Could you share pictures of the silicon on these boards with it clearly labeled which is working and which is not working.

Here you will find a description of the device marking.

Thanks,

Angie

old 03.04.00.03 SDK fails on this chip but passes on "QG" labeled parts

By the way the QG chips are also 678A (2.0)

I don't believe i answered your NRESET comment.  We toggle NRESET active for 100ms before SPI programming in both working and failing cases.  (and NRESET is held active long after power up rails all stable in both cases)

if this is helpful

1. all boards fail to run on the rftest firmware from sdk 03.05.00.04

2. all boards run with success on the rftest firmware from sdk 03.05.00.04 with calibration read from the qspi eeprom disabled

3. new boards (we think BG or specific lots?) fail to run the rftest firmware from sdk 03.04.00.03

4. old boards (we think all QG) runs with success on the rftest firmware from sdk 03.04.00.03
   
   WE NEED TO UNDERSTAND #3, WHY NEW BOARDS FAIL WITH OLD SDK THAT WORKED FOR 2+ YEARS

Shawn,

There are a lot of symptoms here, and I think we need to kind of get this organized in order to narrow this down. Could you put together a matrix of the results seen, where 1 axis is the part number, and the other is the software image that is being used, with the results in the table? I will include a small example of what I mean below. It would also be helpful if you could provide an image of each part (similar to image above), include the exact binary which is flashed (ie what sdk version, path to binary, etc), and as much detail in the results as possible (what/how is failing)

If there is any information which you do not feel comfortable sharing on the public forums, let me know and we can take this offline. 

Best Regards,
Alec

Hope this helps Alec,

Hi,

Perfect, this helps quite a bit. My concern was less related to the Q vs B, and more so to ensure that none of them had an S, which could definitely have impacts here. A couple of questions:

Can you comment on EXACTLY what lines you are commenting out in the bottom row? This will help me to look at what is causing it on SDK3.5, and then hopefully translate that to SDK 3.4.

Is the error behavior identical on REVB and REVC when you use SDK 3.4 and SDK3.5? It seems odd considering that the calib save and restore (which utilizes the QSPI) was not added into SDK 3.5, which seems to conflict with some of our other information. 

Best Regards,
Alec

We're getting into detail we would prefer to go offline, please provide your email, thanks.

Hi,

Understood. I have reached out to your field representative to get that started. I will update this thread with the resolution afterwards for any other users of the forums.

Best Regards,
Alec

Hello Alec, 
Can we get that rep info today, this is escalating to very high priority?

My chart was a bit flawed, the error behavior is NOT identical on REVB/REVC when we use SDK 3.4 and SDK3.5.  3.5 error = "@debugAssert(0)  the IWR6843's MCU goes into an error state".  3.4 Error is NOT understood
3.5 works if we remove:
/* Calibration save/restore initialization */
if(MmwDemo_calibInit()<0)

{

System_printf("Error: Calibration data initialization failed \n");

}

The last row of chart above is seemingly the potential resolution BUT we need your help to understand the 3.4 errors with only we still believe the "B" SIL-2 variant.  Why is 3.4 failing with "B"?
Does "B" require SDK x.x minimum, perhaps?