• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 30 subscribers
  • Views 449 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.

TM4C123BH6ZRB: Uniflash doesn't program the first 1kB of flash memory when reading intel hex file

Lothar Eichelberger
Prodigy 30 points

Part Number: TM4C123BH6ZRB

Hello

I have a minimal program which fits in the first kB. The hex-tools output produces the intel hex file. It shall be loaded with Uniflash.

However, the .hex file is somehow not written, the memory region from 0x00 to 0x400 remains cleared (0xff).

If I try with the .out file it works. If I try with a greater .hex file (merging multiple hex files, the region after 0x400 is correctly written.

0640.uniflash_gui_debug_log.txt 
10:11:16:153 log - NWAgentAPI: dinfraConfigue resolved successfully.
10:11:16:311 error - {}
10:11:16:322 error - {}
10:11:16:331 error - {}
10:11:16:332 error - {}
10:11:16:355 error - {}
10:11:16:359 error - {}
10:11:16:389 error - {}
10:11:16:390 error - {}
10:11:16:398 error - {}
10:11:16:402 error - {}
10:11:16:405 error - {}
10:11:16:412 error - {}
10:11:16:413 error - {}
10:11:16:783 error - {}
10:11:16:809 error - {}
10:11:16:811 error - {}
10:11:16:815 error - {}
10:11:16:820 error - {}
10:11:16:822 error - {}
10:11:16:828 error - {}
10:11:16:829 error - {}
10:11:16:830 error - {}
10:11:16:830 error - {}
10:11:17:008 error - {}
10:11:17:008 error - {}
10:11:17:009 error - {}
10:11:17:009 error - {}
10:11:17:030 error - {}
10:11:17:326 error - {}
10:11:18:639 error - {}
10:11:18:647 error - {}
10:11:19:587 error - {}
10:11:19:632 error - {}
10:11:19:708 error - {}
10:11:19:733 error - {}
10:11:19:734 error - {}
10:11:19:885 error - {}
10:11:19:893 error - {}
10:11:19:894 error - {}
10:11:20:822 error - {}
10:11:20:825 error - {}
10:11:21:758 error - {}
10:11:21:761 error - {}
10:11:21:821 error - {}
10:11:21:824 error - {}
10:11:21:926 error - {}
10:11:21:929 error - {}
10:11:21:929 error - {}
10:11:23:539 error - {}
10:11:23:543 error - {}
10:11:23:543 error - {}
10:11:24:929 error - {}
10:11:24:942 error - {}
10:11:24:942 error - {}
10:11:25:334 error - {}
10:11:25:337 error - {}
10:11:25:337 error - {}
10:11:25:706 error - {}
10:11:25:707 error - {}
10:11:28:266 error - {}
10:11:35:050 debug - Target Configuration. Device: tm4c123bh6zrb, Connection: TIXDS2XXUSB_Connection, LP: false
10:11:35:196 debug - ufDS, session.configured, partnum of current session = tm4c123bh6zrb
10:11:35:224 debug - addTargetStateListener on CORTEX_M4_0
10:11:35:279 error - {}
10:11:36:811 error - {}
10:11:36:814 error - {}
10:11:42:488 debug - returning new configure
10:11:45:238 debug - configured
10:12:01:338 debug - returning cached configure
10:12:01:642 debug - connect to core CORTEX_M4_0
10:12:05:919 debug - returning cached configure
10:12:05:922 debug - returning cached configure
10:12:06:058 debug - connect to core CORTEX_M4_0
10:12:06:113 debug - InitMemoryBrowser {"pageInfoList":[{"addrSize":32,"isDefault":true,"mauSize":8,"name":"RAM","wordSize":32}]}
10:12:06:114 debug - currentValTypeLength = 4 currentMAUSize = 1 currentCellSize = 4
10:12:06:114 debug - , options=undefined
10:12:06:114 debug - memory browser: readMem: rowIdx=0, rowCount=150, page=RAM
10:12:06:114 debug - currentValTypeLength = 4 currentMAUSize = 1 currentCellSize = 4
10:12:06:114 debug - returning cached configure
10:12:06:253 debug - connect to core CORTEX_M4_0
10:12:06:367 debug - reRenderTable: 8
10:12:06:368 debug - , options=undefined
10:12:06:368 debug - memory browser: readMem: rowIdx=0, rowCount=150, page=RAM
10:12:06:368 debug - currentValTypeLength = 4 currentMAUSize = 1 currentCellSize = 4
10:12:06:368 debug - returning cached configure
10:12:06:497 debug - connect to core CORTEX_M4_0
10:12:12:794 error - {}
10:12:12:798 error - {}

The console output shows no warnings or errors also when selecting verbose.

I use the XDS200 debug probe (USB) by blackhawk.

Thanks for any help

Best regards

Lothar

7823.ds.log

  • 0
    Prodigy 30 points

    I just downloaded Uniflash and therefore have the newest version (8.0.0.4026).

    By coincidence I found an old version (7.0.0.3615). Using this one, everything works perfectly fine.

    So it seems like uniflash broke somewhere in between.

    Doesn't realy solve my problem but it's okey for the moment.

  • 0 in reply to Lothar Eichelberger
    TI__Guru**** 159715 points

    Lothar,

    I will give this a try.  I should be able to reproduce this quickly and then get a test case put together for our UniFlash team to look at.  The trick is to find a TM4C123G board.  I have one somewhere.  I have the program and .hex created, just need to find a board to test on.

    Regards,

    John

  • 0 in reply to JohnS
    TI__Guru**** 159715 points

    Lothar,

    I found an LM4F120 board that seems to let me load small TM4C123G programs.

    Using UniFlash I can load a .out fine and a raw binary .bin.  Low addresses are being programmed ok.

    For the hex file can you send me the options you are passing to armhex?  I want to confirm that I am generating in the same way.

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 30 points

    Hi John,

    Thanks for your efforts. The utility is setup as follows:

    </tool>
    <tool id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.207904682" name="Arm Hex Utility" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex">
    <option id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.TOOL_ENABLE.436242549" name="Enable tool" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.TOOL_ENABLE" value="true" valueType="boolean"/>
    <option id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.MEMWIDTH.997070924" name="Specify memory width (--memwidth, -memwidth=width)" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.MEMWIDTH" value="8" valueType="string"/>
    <option id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.ROMWIDTH.173213449" name="Specify rom width (--romwidth, -romwidth=width)" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.ROMWIDTH" value="8" valueType="string"/>
    <option id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.OUTPUT_FORMAT.1355325854" name="Output format" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.OUTPUT_FORMAT" value="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.OUTPUT_FORMAT.INTEL" valueType="enumerated"/>
    <outputType id="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.outputType__BIN.404535419" name="Binary File" superClass="com.ti.ccstudio.buildDefinitions.TMS470_20.2.hex.outputType__BIN"/>
    </tool>

    Mainly rom and mem width is set to 8 (there is a realy strange default that causes the output to be split onto 4 hex files).

    I attached my hex file, which I can't program through uniflash. Sorry, attach doesn't work, I simply paste it:

    :20000000000200205D02000063020000630200006302000063020000630200000000000066
:2000200000000000000000000000000063020000630200000000000063020000630200002C
:20004000454A40F60121D16042F8080C4348106010688008FCD25068014214BF4FF0FF3035
:2000600000207047F8B517463B4A844642F2016E02F1180040F80CECD7B1384B5B1E21F0DD
:200080007F0440F8204C06E05CF8044B02F1F805091D3F1FAC5111F07C0601D105690DB9B6
:2000A000002FF1D1036004686408FCD2002FE6D150F8140C1EEA000F14BF4FF0FF30002080
:2000C000F8BDF0B5264D2949A8688D442549814210D12868B0F5806F0CD9296828686A68F2
:2000E000121A4FF4806000F0A7F888B94FF47F30FFF7A6FF1C494FF4806000240860D4F874
:20010000000480F30888D4F80404804720461FE02E684FF480676868B042DED96C68A41B0C
:20012000B4F5806F88BF4FF4806431466846E41C24F00304224600F01BF83846FFF780FF1B
:20014000394668462246FFF78DFF36193F19E2E7064949428D44F0BD08D00F40020042A4B1
:20016000E4FF03004433221108ED00E0FCFBFFFF002A4AD05FEA000C8B071CD1830722D190
:20018000102A08D370B4103A78C978C0103AFBD270BC103238D0042A2CD3082A05D30C2A69
:2001A00024BF08C908C008C908C008C908C092072AD0920F22E00B780370491C401C521E34
:2001C00022D08B07F7D1C30714D18307D8D0121F12D308C903801B0C4380001D121FF8D286
:2001E0000AE008C903701B0A43701B0A83701B0AC370001D121FF4D2121D05D00B7803707B
:20020000491C401C521EF9D160467047084880F308880849086840F47000086000BF00BFE8
:2002200000F020F80020FFF74CFF012000F01CF80008002088ED00E010B50346002A08BFB4
:2002400000200AD05B1E491E11F8014F13F8010F844201D1521EF7D1001B10BDFFF7D6BF0D
:0C0260007047FEE70120704700BFFEE77A
:00000001FF

    Regards,

    Lothar

  • 0 in reply to Lothar Eichelberger
    TI__Guru**** 159715 points

    Lother,

    Ok here is my test.

    First I erase the flash.

    Then I use the Memory view in UniFlash to read it and make sure it is blank

    Next I load the .out

    Read the memory

    Now I erase the memory again and read it back

    Next I load the .hex

    Read the memory

    So for me loading the .hex is working fine into low memory.  Note that I am not checking the box that the file is a binary as it is not a binary file.

    I also have a .bin file generated.  Testing that as well

    Erase memory

    Select to load the .bin, check the box for binary and specify the load address as 0x0000000

    Read the memory

    So for me I get the same result for the .out, .hex and .bin using UniFlash 8.0 on my LM4F120

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 30 points

    Hi John

    Thanks for the test results. Meanwhile I uninstalled both versions of Uniflash and reinstalled Uniflash 8.0.

    It's still the same for me. However, I tested two further images (.hex) which work as expected. It's just the image that I've posted in the previous post that somehow just won't flash. I started to remove one line after the other until it worked. Once I remove line number 11 to 20, everything works fine. I didn't find any errors in the checksum and even when writting a wrong checksum on purpose, it works. It even works when deleting line number 11 alone. So this line seems to be the culprit.

    Thanks for any further suggestions

    Regards,

    Lothar

  • 0 in reply to Lothar Eichelberger
    TI__Guru**** 159715 points

    Lothar,

    So if I replace my .hex with the content from yours I see the same.  The memory is still all FFFFFFFF after loading.

    I also see this error when attempting to read the memory back:

    [8/15/2022, 11:58:58 AM] [ERROR] CORTEX_M4_0: Error: Debug Port error occurred.

    Really odd.

    Regards,

    John

  • 0 in reply to JohnS
    Guru 92251 points
    JohnS said:

    I also see this error when attempting to read the memory back:

    [8/15/2022, 11:58:58 AM] [ERROR] CORTEX_M4_0: Error: Debug Port error occurred.

    If you enable "Debug Server Logging" for Uniflash, as described in Defect Reporting and Logging, does that give more information about the cause of the Debug Port error?

  • 0 in reply to Chester Gillon
    Prodigy 30 points

    Hi

    Happy to hear that it's not just me.

    If I program and then verify I get the following (set to verbose):

    [16.8.2022, 07:26:16] [INFO] CORTEX_M4_0: Writing Flash @ Address 0x00000000 of Length 0x0000026c
    [16.8.2022, 07:26:16] [INFO] CORTEX_M4_0: Performing Mass Erase on Flash memory
    [16.8.2022, 07:26:16] [SUCCESS] Program Load completed successfully.
    [16.8.2022, 07:26:31] [ERROR] CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.

    which makes sense as the memory is still 0xff.

    I enabled "Debug Server Logging" and added the output on the first post together with the GUI log. The file is huge and I didn't find any obvious error, except that percent always remains 0 ("percent":0), while in the working example, the percent sometimes shows a different value.

    Regards

    Lothar

  • 0 in reply to Lothar Eichelberger
    TI__Guru**** 159715 points

    The same .hex on a different M4F device (CC1352R1 in my case) works fine.

    For the LM4 I am using the LaunchPad with the ICDI debug probe.  I can see some additional errors in my ds.log that I have sent on to the team to take a look at.

    John

  • 0 in reply to JohnS
    TI__Guru**** 159715 points

    Something else interesting.  I can load the .hex in CCSv12 fine.  No error from the debug connection and the memory looks correct.

    However in CCS if I disconnect and then connect again the flash is all FFFF.

    If I clear this option in CCS then the flash is not erased when I disconnect and connect again:

    In newer versions of UniFlash it does a disconnect and then a connect after flashing. That is erasing the flash.

    So switching back to UniFlash I can make things work.

    First I click on the "Cortex_M4_0" at the top right and select to remain connected:

    Then I also clear the option to "Reset target during program load to Flash memory"

    Regards,
    John

  • +1 in reply to JohnS
    TI__Guru**** 159715 points

    Ok we know a little more about what is going on.

    In UniFlash 7.1 there was a change where we don't automatically do a reset after program load.

    As a result here what happens is you load the hex file.  The PC gets set to 0x0 then when it runs from there the flash gets erased.  You can actually see this a bit better in CCS as you can load the .hex and then just do asm steps until you see it get erased.  Why the program does this is not something I can answer.

    However if you load the .hex and then do a core reset the PC gets set to 0x25C which is after the code that is erasing the flash.

    So an easier workaround than what I have above is to click under reset options to get a list of available resets.

    Then select to do a core reset after the program load as this will ensure that it runs from 0x25C and not 0x0.

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 30 points

    Hi John,

    Thanks a lot for your investigations. I tested it and it works, perfect!

    So basically it writes the flash and immediately erases it afterwards if not doing a reset?

    Why did it happen with one image but not with the other?

    I don't really get how I can step the code while flashing through a debug probe. Is there a program loaded that does the actual flashing afterwards?

    While it solves my issue, it's a bit worrying me that it doesn't work by default and that the solution is not obvious.

    Regards

    Lothar

  • 0 in reply to Lothar Eichelberger
    TI__Guru**** 159715 points

    Lothar,

    As far as why it happens with one image but not the other makes me believe that it is the image itself that is triggering the erase.

    In both scenarios, the program runs after flashing but without that reset it runs from 0x0.  So something in the one image between 0x0 and 0x25C is causing the erase.  I suppose you could load the image in CCS and then open the disassembly view and put the starting address at 0x0 and it will show what the instructions are.

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 30 points

    Ahh know I understand, it's the application that erases itself by accident.

    It has indeed the tivaware FlashErase() function inside. By starting at PC=0x00, the vector table is executed as some random code and somehow it runs into the FlashErase() function which then erases itself...

    Through the reset, the PC is properly loaded from the vector table and the program runs properly, hence doesn't erase itself.

    Why would you run the program from a random address (0x00) as default?

    Does it mean I have to secure the FlashErase() function with some function argument value?

    Many thanks for above pointer.

    Regards,

    Lothar