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.

uniflash trouble

Other Parts Discussed in Thread: UNIFLASH, TMS570LS0432

Hello

I need sanity check if I'm doing this right.

1. I start a new project select the debugger XDS200 and TMS570LS043x.

2. I add a hex file under the programs tree node. (it adds to the list an no complaints)

3. Press program and program shows a progress bar and becomes unresponsive for a long period and finally reports trouble wrinting memory block at 0800a5ca.

I've attached a screen short.

I have no problem downloading and verifying using IAR EW and the XDS200 debugger on the same board. 

What is wrong?

Best Regards

Henrik Liljedahl

  • The address mentioned in the message 0x800a5ca seems strange. Isn't that reserved memory on the TMS570LS043x?

    Do you only have the .hex file or do you also have access to the equivalent executable (.out file) to try loading that using Uniflash? Have you tried loading other programs or hex files to see if they all exhibit an error?

  • Yes, It's a reserved address. The funny thing is that my hex file only contains addresses from 0x0 to 0x3DEC0. I believe there is nothing wrong with my hex file and it should work. The failing address is not even in my hex file. 

    I've made a test creating a new project from ccs and took it's out file and it does get programmed ok. So there is nothing wrong with my XDS200 and the connection to my TMS570LS0432 rev A. 

    I've also tried an "out" file. It's generated by IAR EW, but it should be ok, right?

    When programming there is a new error at yet a reserved address.

    Best regards

    Henrik Liljedahl

  • Can you attach one of the hex files or .out files that generate this error, so we can try to analyze it? Since you mentioned that the .out file created from a new CCS project loads ok, so it seems specific to some .hex/.out files.

    Are all the problematic files generated by IAR? How was the .hex file created?
  • Yesterday, I did manage to program both the hex-file and the out file generated by IAR! But that didn't last long...today when testing the same files I get the following error :

    After I get this error the uniflash is no loger responding and needs to be killed from the task manager.

    I guess there is nothing wrong with the files and how they are read by the uniflash.

    Is it possible to set any parameters like JTAG clock speed?

    Best regards

    Henrik

  • Henrik Danielsson said:
    Is it possible to set any parameters like JTAG clock speed?

    I don't see a way to adjust the JTAG clock in Uniflash, but you can do it from CCS (by opening the target configuration file and going to the Advanced tab in the editor), and then open that modified target configuration from Uniflash.

    If you can send us the .hex and .out file that you are trying to load that will really help us look into what could be happening here.

  • I have done some more testing here and did discover something interesting... When I compile the code as arm, then uniflash manage to program the IAR out file. If I take the same program and compile as thumb then this new out file is getting the errors seen before. But this is just for my project. If I generate a new project then arm or thumb doesn't matter. I guess the problem is seen only in somewhat larger out files.

    I now have two files one compiled in arm mode (programs ok) and one compiled in thumb mode that doesn't work.

    EDIT: I forgot to say hex and out file are the same behaviour. hex files attached, if you need the out files let me know.

    uniflash trouble.zip

  • Henrik Danielsson said:
    hex files attached, if you need the out files let me know.

    Yes please. Could you attach the .out files as well? Thanks!

  • AartiG, A private message is sent to you with a link to the files.
  • Henrik,

    Thanks for providing the program files. After doing some investigation, we discovered a problem with the Hercules Flash programming logic, specifically loading segments that are not 64-bit aligned as is the case with the program you provided in thumb mode.

    We have implemented a fix for this, and will be available as part of the next CCS release (currently scheduled for early next year). The bug can be tracked via ClearQuest SDSCM00052413.

    If you need a solution earlier, I might also be able to create something for you for testing purposes.

    Thanks,
    Ricky
  • Ok, sounds like good news.

    I was hoping to use the uniflash in production planned for december. Do you think you can have a solution for us by then?

    Best Regards

    Henrik

  • Henrik,

    We don't have a schedule for the next UniFlash release/update available at this time. But we do have a few bug fixes in the pipeline, so there is a chance that there will be a release before December. I will try to keep you updated on the release schedule.

    Alternately, you can try out the following temporary solution. It hasn't been fully tested yet, but is reported to fix the problem you initially reported.

    Instructions:

    1. Download the attached FlashHercules.dll

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/FlashHercules.dll

    2. Copy the file into the following folder in your UniFlash install (I tested this in the latest UniFlash 3.4 release):

    <installDir>\ccs_base\DebugServer\bin\

    3. Retry loading your program compiled in thumb mode again.

    Thanks,

    Ricky