• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 766 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWR1243: SPI Firmware Download Error

Antonio Puglielli
Expert 1025 points
Part Number: AWR1243
Other Parts Discussed in Thread: , UNIFLASH

Hello,

I am attempting to download firmware over SPI to an AWR1243 device (ES 2.0) on the AWR1243BOOST board. Our host processor is an FPGA interfacing through a breakout board.

After de-asserting reset, the AWR1243 device transmits a AWR_AE_DEV_MSSPOWERUPDONE_SB message, with power up status field set to 0 and power-up time around 2.8ms.

For the purpose of this test I am sending the BSS firmware in 40B chunks, across 4918 messages. The first message I transmit is (hex):

1234 4321 8105 003A 0000 1335 0001 6B8A
4080 002C 0000 0000 0054 0003 5AB5 D103
0300 5000 0000 0500 0000 0000 FFFF A0E1
0000 0400 0000 FCFF 0000 0000 739B

However, the AWR1243 device responds with an error message, with no sub-block information:
DCBA ABCD 0016 000E 000C 0000 0001 FFCE CDCB

I have never seen this type of error message and it is not documented anywhere. The confusing part is that the error message contains no sub-block information, despite the NSBC field set to 1.

I have tried the following debugging steps, with no change:
- Varying the message length
- Varying the clock speed
- Deliberately sending incorrect checksum. The radar does not respond as expected.
- Deliberately sending incorrect CRC. The radar returns a properly-formatted NACK as expected.

What may cause this issue, and how can we fix this?
Best,
Antonio
  • 0
    TI__Genius 15005 points
    Hi Antonio,

    I am looking into this and will need another day.

    I suspect this might be due to the message length being different from what we use in our examples. Is it possible for you to use a message length of 232 bytes of data plus the headers like we do?

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points
    Hi Anand,

    Thanks for looking into this for me.

    I did try using length 232, and I see the same behavior. Here is the start of packet:

    1234 4321 8105 00FA 0000 034F 000a 7AB0
    4080 00EC 0000 0000 0054 0003 ...

    I get the same empty error response. I also tried with the MSS and memswap firmware files and had the same result.

    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    Expert 1025 points
    Hi Anand,

    I tried three other tests.

    1) Send deliberate incorrect FILE_TYPE field (set to 0x10) and FILE_LENGTH ( set to 0). No change in the error message.
    2) Send an 8B payload (just the FILE_TYPE and FILE_LENGTH fields, no firmware file in first packet). No change in the error message.
    3) Send a properly formatted AWR_DEV_RFPOWERUP_SB message. I got an ACK, but obviously the BSS did not power on afterwards.

    This suggests to me that:
    1) The SPI engine is properly running on the AWR1243.
    2) The error is detected either in the message header, sub-block header, FILE_TYPE field, or FILE_LENGTH field.

    Would you agree with that? What would be a next debugging step to try?

    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    Could you please confirm for me the exact firmware image that you are using? Which version of the DFP package was it from?

    Thanks,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points
    Hi Anand,

    I am using DFP 1.0. I have got the BSS, MSS and memswap firmware images from this package. When I flash them onto BOOST board using Uniflash, they work correctly with this silicon version (ES 2.0).

    In case it helps identify them, the binary sizes are:
    MSS: 98332B
    BSS: 196692B
    Memswap: 164B

    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points

    Hi Antonio,

    We looked at your SPI trace and I would like to point out one issue. It appears the byte order that you are using for the data is again incorrect.

    The correct first message would be something like the following:

    0x1234 0x4321 0x8105 0x003A 0x0000 0x1335 0x0001 0x6B8A

    0x4080 0x002C 0x0000 0x0000 0x0054 0x0003 0x03D1 0xB55A

    0x0050 0x0003 0x0005 0x0000 0x0000 0x0000 0xE1A0 0xFFFF

    0x0004 0x0000 0xFFFC 0x0000 0x0000 0x0000 0xFA3A

    Note that your message is identical up to the 14th word. The data from the next word onward appears to be swapped at the 32-bit level - I guess this is again a consequence of using a big-endian host.

    If you could fix this, I think you should be good to go.

    For reference, I'm attaching a trace file from our EVM showing successful firmware downloads with the same chunk size as you.

    Hope this helps.

    Best Regards,

    Anand

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/trace_5F00_ES2_5F00_firmware_5F00_download.7z

  • 0 in reply to Anand Gadiyar
    Expert 1025 points
    Hi Anand,

    That did resolve the issue. Thanks very much for your help - very useful as always.

    Best,
    Antonio