• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 822 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6748: Serial Flash Loading Utility for OMAP-L138 hanging when programming an 8-bit bus NAND Flash chip

Chris Widdis
Prodigy 100 points
Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAP-L138

We are having issues with a re-compile of the "TI Serial Flasher Host Program for the OMAP-L138" version 2.40 - it is hanging during the "Programming application into flash ..." step.

Background:
We have a custom board that uses the C6748 DSP chip. The board recently switched from a 16-bit NAND Flash chip to an 8-bit NAND Flash chip, which is used as the boot device for our firmware. We had been using the serial flasher host program to load firmware on 16-bit NAND Flash chips successfully.

Where we are:
- I went through some other forum posts (link) and the wiki for the tool (link) and got the utility to build successfully after changing "device_async_mem.h" to have DEVICE_ASYNC_MEM_NANDBOOT_BUSWIDTH set to (DEVICE_BUSWIDTH_8BIT). This was done after running "make clean", with "make" being executed from the GNU folder.

- As a sanity check, I recompiled the original source code of the utility to make sure that the tool-chain wasn't the problem - this worked and I was able to flash the old 16-bit bus width NAND Flash chips.

- I created a small Flasher firmware application that can be loaded through the JTAG debugger using CCS. It reads the firmware image off of an SD card and programs the NAND Flash chip, which was successful. We are using that as a fallback solution, but would much rather not have production require access to the source code repository / CCS / debugger to do our initial load of firmware on boards.

- The new 8-bit chip we are using is MT29F2G08ABAEA. The old 16-bit chip we were using is MT29F4G16ABADA

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 114410 points
    Chris,

    The utitlity should already have support for 8 bit and 16 bit NAND as TI EVM had a 8 bit NAND and the LCDK platform has a 16 bit NAND.

    For 8 bit NAND
    sfh_OMAP-L138.exe -targetType C6748 -flashType NAND -p <COM_Port_Number> "<Ais_File_Name>"

    For 16 bit NAND
    sfh_OMAP-L138.exe -targetType C6748_LCDK -flashType NAND -p <COM_Port_Number> "<Ais_File_Name>"

    The same applies to the CCS based NANDWriter code that can be located at OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\CCS\NANDWriter
    The same NAND writer works on both 8 bit and 16 bit NAND with the only change being the following in nadwriter.c

    //#define NANDWIDTH_16
    #define NANDWIDTH_8

    Please give this a try and let us know if this doesn`t work.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 100 points

    It did not work.

    Using the C6748 targetType, the application gets hung up a step earlier, on the "Waiting for SFT on the OMAP-L138..." line. Perhaps there are different clock / DDR RAM settings associated with the 2 targetTypes that are incompatible? Also note that we are using the -flash_noubl keyword.

    I have not tried building / using the NANDWriter - from what I can see, it is loaded through the debugger in CCS. Is that correct? If that is the case, we can just use the CCS build configuration we already have for that purpose.

  • 0 in reply to Chris Widdis
    TI__Guru** 114410 points

    the EVM is using mDDR while the LCDK is using DDR2 memory. they both should be using the same clock configuration so that shouldn`t matter.

    Yes, the NAND Writer needs to be loaded and run using JTAG debugger and CCS.  Note the project provided in the package are CCSv3.3 projects.

    HEre is a document to build this using CCSV7.

    Building_CCS_based_Flash_Writers_Serial Flash_and_boot_Utilities_in_CCSv7.docx

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 100 points
    I should note that this is on a custom board, not one of the eval boards. We are using DDR2, which may explain the problem with using "-targetType C6748"?

    Can you think of any other place in the sfh_OMAP-L138.exe code that would need to be changed other than "device_async_mem.h" and the DEVICE_ASYNC_MEM_NANDBOOT_BUSWIDTH macro when changing the NAND Flash chip on the board? Perhaps there is somewhere that maps timings/parameters to device IDs? I did not find such a thing, but I have not dug too deep into the code yet.

    As I said, we already have a CCS build configuration to load the binary into NAND flash through the JTAG debugger using our own code base for this board (it reads the .bin file from an SD card and writes it to the NAND Flash), so there isn't really any point to investigating the NAND Writer (unless it could point to the source of the problem with sfh_OMAP-L138.exe).

    Thanks,

    Chris