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.

Struggling to Write Data to External FLASH

Hi fellows!

I am struggling to interface a M29W160ET FLASH to the C5509A EMIF.

When we try to read data from FLASH we keep reading only the last written data no matter what address we put at the bus, as if it was "saved" into a latch. When we reset the power of the system and do not write any data, we only read 0, which means we have not written data to the FLASH.

I used the functions from DSK_5509A library. We looked at the EMIF configuration and timings several times. I am using the bus address pins A[0:12] of the FLASH connected to A[13:1] of C5509A. We have verified the control signals (CE1, OE, WE, A0 and D0) with a scope and they seem to be ok.

I believe I may be missing something basic, do you have any idea of what could it be?

Thank you in advance!

 

  • Hi,

     

    Are you using a custom board or C5509A DSK?

    Can you tell me your memory map?

    Have your address lines checked with a scope? 

    Regards,

    Hyun

  • Hi Hyun, thank you for your reply!

     

    I am using a Custom Board.

    I am using a SDRAM memory in CE0 address (byte address 0x040000 length 0x3BFFFF) and the Flash in CE1 address (0x400000 length 0x3FFFFF). I have created vectors mapped with #pragma and the data stored in SDRAM works fine.

    I have checked the A0, A1 and A2 pins of the memory with the scope as well as data pins D0, D1 and D2 and the bus control lines CE, OE and WE, as you mention. They are ok.

    Since I am not experienced in using external Flash, I am working now on the hypothesis that the memory blocks comes fully protected from factory.

     

    Thank you again!

     

    Regards,

    Nelson

  • Ok. Sounds good. If you have any other questions, please let us know.

    Regards,

    Hyun

  • It works now!

    The normal operation of the chip is protected, so every time the user wants to write to the Flash he has to run the unprotect procedure, at least until power off.

    Now I will try to load an executable code. The code I generated using hex55 seems not to be the executable kind.

     

    Regards,

    Nelson

  • That's great!

     

    Another way you can check is as following:

    After you program the flash, use a debugger to read values in memory to check you programed correctly.

    Regards,

    Hyun

  • Thank you for the suggestion Hyun, I have made it, but the code does not run... I generated an executable code using hex55. I have also compared this code with the hex disassembly using the CCS debugger, and they are the same. After programing the Flash memory with this code, I have powered off the system and read the data of the Flash again and the code was still there, which means that it was indeed written to the Flash. Although, when I place the bootloader to execute from Flash, adjusting the value of BOOTM pins, the code does not run. I have read the data in the Flash and the code starts at byte address 0x400000, but even so it is not running. I have also tried to load only the code after the main function, and nothing changed. Do I need to configure something in the bootloader to execute directly from Flash? Do I need also to allocate CSL data, interrupt vectors and other data on the Flash address either? Regards, Nelson
  • Have you check your code first using Debugger? It runs.

    Next step is to check your code correctly copied to internal memory from Flash by bootloader.

    Regards,

    Hyun

  • Hi!

    Thanks Hyun for the quick answer.

    I have checked the code and it runs ok using debugger. The code is just for blinking two LEDs. I also ran it on hardware using USB bootloader, loading the code in internal RAM address, and it ran ok. 

    Although, I need this code to be executed directly from Flash (BOOTM[3:0] = 0001). 

    What I made was to use hex55 to generate an ASCII code that is the same as shown in the debugger and then write it to the Flash. In this case, the data is a vector containing bytes corresponding to the code hex representation, that is 0x4e, 0xff, 0x6c, 0x40 and so on, which corresponds to the code shown in the debugger from address 0x400000 on (shown in "Disassembly" in figure below). The debugger also runs ok when loading the code at Flash address.

    I am worried about CSL_init( ) being loaded at 0x400000 instead of main. Is it possible to run the code directly from Flash this way? Do I need to make additional configurations?

    Thanks again!

    Regards,

    Nelson

     

  • hi,

    You need to include -e option in your hex55 building stage. The entry point is the stating point after code moved to internal memory.

    -e your_entry_point (When you check your map file, you will see where is your entry point.)

    Regards,

    Hyun

  • Hi!

    I have tried to include -e and it did not work...

    I made two firmwares, one for blinking the LEDs, mapped to the external Flash, and one for writing data to the Flash, using USB bootloader and Thesycon USBIO software.

    I used hex55 to generate the blinking LED firmware binary using options "-parallel16" and "-bootorg 0x400000". With your suggestion, Hyun, I also made the same adding options "-boot" and "-e 0x00400324". I got the entry point from the file generated using option "-map".

    In the Flash writer firmware, I created a Uint16 vector which data are the bytes from the file generated applying hex55 to the blinking LED firmware using option -a, to generate ASCII output.

    When I switch jumpers of the BOOTM pins to go from "USB Bootloader" to "Direct Execution from External Asynchronous Memory", nothing happens.

    Is there another way of loading an executable code to Flash and executing the code directly from it? Is it possible to do it without a specific tool ?

    Thanks again!

    Regards,

    Nelson

     

  • Hi,

    There is some miscommunication. I expected that you boot from internal boot code and internal boot move flash code to internal memory. After that it runs from internal memory.

    Is this what you want? Or you want  to run from flash directly?

    Regards,

    Hyun

  • Hi!

    Sorry for the miscommunication.

    It is the second case, I want to run from flash directly. Can I do it?

    Regards,

    Nelson

     

  • Hi,

    Why do you want to run it from flash? It'll be slow down your processing.

    That is tricky to do this. You need set flash read mode first and who is going to this? Normal procedure is bootloader taking care of this part.

    If you want to do this, this is steps you need to go through.

    1. Create a small bootable code will sit in the flash.

     2. Include flash read mode and set initialization on emif.

     3. Create another main code to sit another location in the flash.

     4. After load the the first code and at the end of excution, jump to the your main code location.

    Regards,

    Hyun

  • Hi!

     

    We would like to run directly from Flash because we did not know if the code would fit internal RAM and we left performance to be issued afterwards. Although, from what we have read on the Bootloader reference guide, we thought it would be far more easier than it really is to do this ...

    Anyway, we tried to follow these steps.

    We stored the code for blinking two leds on the beginning of the Flash memory. Then, we created a code to put Flash into read mode, sending data 0xF0, and then jump execution to external flash using asm(" B #0x400000"). This code was loaded through the USB Bootloader and runs. Though, I am not sure of where to jump to, if it is the entry point (_c_int00) or main. We tried both and it did not work.

    Also, since the code is stored in word size, we tried also to half the addresses and write the code to the Flash in word (16-bit) format. No change.

     

    Anyway, given the difficulties in executing directly from Flash, I believe that perhaps it would be really wiser to forget this and follow your advice, Hyun, and make parallel memory bootload insted.

     

    Thank you!

     

    Regards,

    Nelson

     

  • Hi,

    That's good idea to work a normal way. If you think that your code size will be bigger than internal memory, you may add external SDRAM as well.

    Regards,

    Hyun

  • Hi!

     

    That is a good suggestion I have not considered, thank you Hyun.

     

    Just to clear some doubts that I have about the normal Flash bootloader, I am writing to the external Flash the boot table generated with command:

    hex55 <file.out> -boot -v5510:2 -parallel16 -a -o file.hex -map file.bxp -e 0x00000424

    In the linker file I started mapping .text from 0x200 on. I also checked the .hex file and it indeed has the entry point address and same format as stated in the Using Bootloader reference guide. 

    Then, I wrote the ASCII hex code in the .hex file to the Flash and changed jumpers to parallel 16-bit bootload. Although IO4 goes down and high, nothing happens and the code is not run. I also tried configurint CLKMD and EBSR using -reg_config 0x6C00,0x8201 and -reg_config 0x1C00,0x0810, but nothing changed.

    Do I need to write to the Flash in words instead of bytes? I mean, joining bytes, eg. 0x00 0x04 becoming 0x0004?

     

    Regards,

    Nelson

     

  • Hi!

    I created another post since the discussion evolved to another topic.

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/105185.aspx

    Thank you!

    Regards,

    Nelson