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.

CCS/AWR1642: Problem downloading firmware into AWR1642 RAM

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

Tool/software: Code Composer Studio

Hi,

We've designed our own board with the AWR1642. Here is the toolchain we are using:

- CCS7.2

- MMWAVE SDK 01_01_00_02 (SYSBIOS 6.52.00.12 + CGT-ARM 16.9.6 LTS + XDC 3.50.02.20)

- Blackhawk USB560 V2 System Trace + Mipi60 to ARM-20 adapter

We have successfully flashed the xwr16x_ccsdebug.bin file into our board with the UniFlash V4.

The connection to the Emulator is ok, as well as the connection to the Cortex R4_0. After reset the CPU, we try to download our firmware, but we encountered always the same error:

Cortex_R4_0: File Loader: Verification failed: Target failed to write 0x00000000
Cortex_R4_0: GEL: File: C:\Tools\TI\workspace\Hello\Debug\Hello.out: Load failed.

It is working fine when we try to download the same firmware into the AR1642EVM-011+AR1XXXEVM-012 with exactly the same configuration except that we are not using the mipi60 to ARM20 adapter.

Could you please advice us or tell us what we did wrong ?

Thanks a lot,

BR,

Laurent

  • Hello Laurent,

    You typically get this error if you have set the SOP settings  in Flash mode(SOP2 SOP1 SOP0 = 101).

    To download the code to the device you will need to be in the Functional mode (SOP2 SOP1 SOP0 = 001).

    The signal TDO is high and PMICOUT is low and SYNCOUT is low in the functional mode.

    Please check these signals before you try to download the app code using CCS.

    Thanks,

    Raghu

    ---------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    ----------------------------------------------------------------------------------------------------------

  • Hi Raghu,

    Thanks for your reply.

    I checked the SOPx signals and there are all correct. The chip is then in functional mode (001).

    I noticed that the ERROR_OUT signal is low. I suspect that something goes wrong in the bootloader and then it does not jump in post-eclipse view as described in chapter 3.5.2 of AWR1642 TRM. This could explain why I get this error un CCS (failed to write at address 0).

    I then probes the QSPI flash to see what the bootlooder is doing and I got this:

    READ SFDP : 5A 000000 53 46 44 50 06 01 01 FF

    READ STATUS: 05 00

    READ ID: 9F 01 60 17 FF

    READ SFDP: 5A 000008 00 00 06 01 10 00 03 00 FF

    READ STATUS: 05 00

    READ SFDP:  5A 000300 00 E5 20 FB FF FF FF FF 03 48 EB 08 6B 08 3B 88 BB

    READ STATUS: 05 00

    QUAD OUTPUT READ : 6B C0 C0 C0 C0 .............................

    The beginning is very similiar to what is desrcibed in the AWR1642 Bootloader Flow document, but the QUAD OUTPUT READ seems to be wrong. I've the signal Q3 and Q2 that are always high. Q1 is always 0 and  Q0 seems to be ok.

    When I flashed the ccsdebug.bin file with UniFLash tool I didn't get any error (but I do not know if the tool is verifying the flash after it has programmed it.).

    Is my flash well supported by the bootloader ? The type is SF25FL064L. In the AWR1642BOOST, you used the S25FL132K but is not recommanded for new design.

    BR,

    Laurent

  • Hi Laurent,

    We have a known interop issue with SFLASH variants that support extended addressing mode, as in case of S25FL064L.

    Known Issues:
    The ROM bootloader in XWR1642 pre-production devices in not compatible with SFLASH variants that support extended addressing mode. In particular, the “Number of Address length” field of the SFDP command response being non-zero is not supported. The total SFLASH addressable region in XWR1642 devices is 8 MBytes. So “Number of Address length” = 0 (corresponding to 3 bytes address length) will satisfy the addressable range. However, the compatibility issue is with variants that allow for “3 or 4 bytes address length”.
    This incompatibility will be addressed in our production version of the XWR1642 silicon.

    Could you please consider connecting an alternate SFLASH part? As stated above, you will be able to work with the part SF25FL064L on production version of the AWR1642 devices.

    Best regards,

    Naveen

  • HI Naveen,

    Thanks for your feedback.

    I changed the type of flash with a S25FL132K and it solved our boot issue.

    BR,

    Laurent