This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWR1642: Fallback boot from second to fourth flash location is not working

Part Number: IWR1642
Other Parts Discussed in Thread: AWR1642, , UNIFLASH

Hello,

in this forum thread (titled: "AWR1642: Meta Image Size"):

…is written that device bootloader stored in ROM is trying to load firmware meta images from flash addresses 0x0, 0x80000, 0x100000 and 0x180000. In my case I have IWR1642 and it boots only from meta image "slot" 1. If I erase device and flash forking image to slots 2, 3 and 4 and leave first empty, it is not booting. If I flash working image to slot 1 it boots. I need this feature for flashing firmwares/meta images over CAN. I've got CAN working, I am able from my app read, erase and write to flash but without this auto fallback boot feature which it should have it will be needlessly more complicated. I even tried to flash only first 32 bytes of working program to force it to load header/part of header and force it to fail integrity check and move to next flash boot address but without success. (I’ve checked, that it was written OK.) What am I missing?

Chip complete label is as follows:

IWR1642

QG

86ZDPP9

502AC         ABL G1

I hope it’s not some old buggy silicone.

We are using our own boards but they are mostly schematically copies of evaluation board schematics but everything seems to be working even flash and I read entire flash via my application in ARM core and there was what uniflash written to it.

Thanks for advises.

Best Regards

Petr

  • Hi Petr,

    Can you confirm you are using UNIFLASH utility or otherwise?

    We'll need a few days to look into this.

    Regards,

    AG

  • Hi Akash,

    thanks for reply. Yes, I tried UNIFLASH.

    I tried in UNIFLASH format flash, do power cycle and flash same firmware to locations/slots (for metaimages) 2, 3 and 4. I left first blank (without image). After flash success I switched pins to working/executing mode and did power cycle again. It didn’t boot. When I uploaded debug code via Code Composer Studio, it was able to start and within my software I’ve sent myself via serial port content of whole 2MB/16Mb of flash to my PC. It was flashed as it should.

    If I flashed firmware to all slots including the first one, it booted. If I erased first 512KB of flash within my program it again didn’t boot after warm reset or even real power cycle.

    If I again checked content of flash from my program running on MSS, there was firmware on location/slot 2 was there as flashed originally with UNIFLASH. On our board we use same flash chip as on evaluation board. Except power source and change that debugging probe is unplugable and is on separate board it should be the same like on evaluation board.

    My thought is if your bootloader in ROM skips segment if it finds in the first 512kB of flash all bytes with 0xFF value? Are there any other necessities to make it fork correctly?

    Screens of flash parts in our schematics (but external flash itself works and it boots from first location):

    Thank you.

    Best Regards

    Petr

  • Sorry, here are schematics mentioned in previous post

  • Hi,

    Have you looked at the Secondary boot-loader over CANFD:

    http://dev.ti.com/tirex/explore/node?node=AIbEoly4B7.jPYk1aCiO-A__AocYeEd__LATEST

    I guess this is what you are trying to do using meta image 2/3/4.

    Now for the original issue:

    If you refer to section 2.1.1 @https://www.ti.com/lit/an/swra563/swra563.pdf

    Fallback images: the bootloader supports loading of images from the following locations as a fallback mechanism if one of the images is corrupted in the SDF. The locations of the images are: – META IMG1(SDF offset – 0x0) – META IMG2(SDF offset – 0x80000) – META IMG3(SDF offset – 0x100000) – META IMG4(SDF offset – 0x180000)

    The meta image should be corrupted. Please refer to the Image Creator user guide available in the mmWave SDK release for image format details.

    Thanks

    Yogesh