• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 35 subscribers
  • Views 1950 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.

IWRL6432: Flashing Device

LJKW
Prodigy 130 points
Part Number: IWRL6432
Other Parts Discussed in Thread: , UNIFLASH, SYSCONFIG

Good day, 

Just some context: I am in the process of evaluating the IWRL6432 and have created my own board. I am running into some issues bringing this board up, so I am trying to narrow down where the potential issue may be. 

We are not using the XDS110 on our boards. Instead we have our own separate debug board that converts from USB to UART through an FTDI chip. When using the low power visualizer to flash our board, we therefore have to manually specify a COM port as we are not using an XDS. We then flash an .appimage file onto the device, the same one we have been using successfully with the IWRL6432Boost EVM. We are seeing activity on the UART lines (Green is UART-RX and Yellow is UART-TX) when flashing.

The visualizer then says that flashing has been successful:

 

I would like to clarify exactly what successful means here: 

1. Is there any verification performed to confirm that the .appimage has been stored in external flash successfully? 

2. Or does it just write the .appimage to flash and once it has finished writing it just automatically assumes it has successful?

3. Since it says it was successful, can we make the assumption that our external flash we are using on this board is compatible and working as expected? Does the external flash acknowledge that it has received the .appimage successfully?

4. We are using MX25R1635F for our external flash, whereas your EVM uses MX25V1635FZNQ03. MX25R1635F and MX25V1635FZNQ03 are seemingly compatible and no changes should be required in the FW to ensure compatibility?

Your input is much appreciated. 

  • 0
    TI__Expert 8802 points

    Hi,

    Please allow the appropriate member on our team another day to respond to this.

    In the meantime. Have you tried flashing through the standalone Uniflash program? It is generally more verbose with its output as it is flashing the device.

    Regards,

    Tim

  • 0 in reply to Tim Henderson
    Prodigy 130 points

    Hi Tim, I have just flashed it with Uniflash now. Here is the output: 

  • 0 in reply to LJKW
    TI__Mastermind 37760 points

    Hi,

    I would not assume that error checking is being run when you flash the device, but we can forward this to the Uniflash team to comment.

    Best,

    NAte

  • 0 in reply to Nathan Block
    Prodigy 130 points

    Hi Nathan, 

    If we could get an answer on whether error checking is being run, that would be much appreciated. 

    I think we are slowly narrowing down what the issue is:

    According to this post, we were not aware that it seems like only MX25V1635FZNQ Flash part is currently supported by the SDK:  https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1237197/iwrl6432-can-the-flash-mx25l3233fm2i-08-be-used?tisearch=e2e-sitesearch&keymatch=IWRL6432%252520Flash# 

    We are currently using MX25R1635F (wide voltage part variant). I see that this Macronix Flash IC is supported on other TI platforms:

    Looking at the sysconfig below for the IWRL6432 SDK, it shows that there is only support for MX25V1635F:

    Please could you advise what fields we should change in the sysconfig to make this device compatible with the MX25R1635F? I imagine it should be minimal as the MX25R1635F and MX25V1635F Flash ICs seem very similar. 

  • 0 in reply to Nathan Block
    TI__Guru**** 462871 points
    Nathan Block said:
    I would not assume that error checking is being run when you flash the device

    Basic (partial/quick) verification is done by UniFlash after flashing the image.

  • 0 in reply to LJKW
    Prodigy 40 points

    Hi all,

    I've been helping Luka debug his board from the software side. With our firmware that was adapted from the motion_and_presence_detection demo, which runs successfully on the IWRL6432BOOST EVM, we get the following error messages:

    [Cortex_M4_0] ERROR: Board_flashOpen:168: FLASH open failed for instance 0 !!!
    Calibration Invalid
    ASSERT: 0.3844s: ../motion_detect.c:motion_detect:4206: 0 failed !!!

    The assert fails because MmwDemo_calibInit returns an error code when called in motion_detect.

    After some investigation, we found that in the .syscfg file, the Flash JEDEC Device ID is set to 0x2315, which matches the data sheet of the MX25V1635F used on the EVM, while that of the MX25R1635F on our PCB is 0x2815.

    After changing this, the flash error disappears, and we only get a calibration error:

    [Cortex_M4_0] Calibration Invalid
    ASSERT: 2.71274s: ../motion_detect.c:mmwDemo_factoryCal:3936: 0 failed !!!

    This assert fails because MMWave_factoryCalibConfig returns an error code in mmwDemo_factoryCal.

    Running the normal ATE calibration procedure from the instruction slides does not fix the issue. So I would guess that changing the device ID in our firmware allows it to interface with the QSPI flash correctly, but this change is not present in the calibration firmware, and so it cannot store the calibration values.

    Does this make sense? Could you perhaps provide us with a way to perform ATE calibration with the MX25R1635F part, e.g with a modified firmware build, or source code for the calibration firmware that we can modify ourselves?

    Thanks,

    Bertus

  • 0 in reply to Bertus Basson
    TI__Mastermind 37760 points

    Hi Bertus,

    I'm glad things are progressing! I am asking about the ATE cal image internally. Let us respond to you in 24 hours. If you don't see a response feel free to ping the thread.

    Best,

    Nate

  • +1 in reply to Nathan Block
    TI__Mastermind 37760 points

    Try this image?

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1023/MX25V1635F_5F00_calibration_5F00_example.release.appimage

  • 0 in reply to Nathan Block
    Prodigy 130 points

    Hi Nathan, thanks for the response. Just a quick question: what is the difference between this appimage you sent now versus the one we have already tried as the name suggests that it is still only compatible with the MX25V1635F and not the MX25R1635F flash variant? 

  • +1 in reply to LJKW
    TI__Genius 11550 points

    Hi LJKW,

    The new image is compatible with MX25R1635F. This image has the device ID changed to 0x2815, which is compatible with MX25R1635F

    Regards,

    Abhishek

  • 0 in reply to Abhishek Karkisaval
    Prodigy 130 points

    Perfect thank you. We can confirm that this image allowed us to store the ATE calibration data in our flash. We can also confirm that changing the device ID to 0x2815 in the sysconfig has allowed us to get things to operate as expected.