• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Subscribers 34 subscribers
  • Views 3149 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.

TM4c1231h6pz Flash Address Space

Cynthia Crutchfield
Expert 1335 points

Other Parts Discussed in Thread: UNIFLASH, TM4C1231H6PZ, TM4C123GH6PM

Hello,

I'm using Uniflash to program 32 bytes of data in Flash via "Program - Load Binary".  I would like the data to be near the end of the Flash and have discovered that Uniflash will return the error:  

ERROR >> CORTEX_M4_0: File Loader: Verification failed: Values at address 0x000000000003F800 do not match Please verify target memory and memory map.

if I attempt to place the data in the last approximately 2K of the Flash address space (failures begins at addresses past 0x3F700).  The data sheet says that the Flash runs from 0x0 -> 0x3FFFF.  I'm suspecting that there is reserved memory space at the end of the Flash, but I can't find information in the data sheet to verify this.  Is this the case?

Thanks,

Cindy

  • 0
    TI__Mastermind 22640 points
    Hello Cindy,

    I am able to program a small binary file into the last page of a Connected LaunchPad board using the menu option "Program->Load Binary Program" in Uniflash. I also verified that the correct binary is stored by using the option "Program->Verify Binary Program". I did not try this on TM4C1231H6PZ part but the process should be the same.

    The start address should be the address of the first byte of a sector. In the case of TM4C1231H6PZ device, if the binary file is 2KB or less, then the start address of 0x3F800 should be used. Is this the address you used?

    Sai
  • 0 in reply to Sai Reddy
    Expert 1335 points

    Hi Sai,

    Thank you for your reply.  Yes, 0x3F800 is the address I tried initially (the last 2k block in the flash).  I'm programming with a 32 byte binary, and I can verify the programming at smaller addresses- I begin to receive error messages as I approach the 0x3F800 address (starting at 0x3F700).  I have a launchpad I can try for comparison.  My chip resides on a custom board.

    Thanks,

    Cindy

  • 0
    Guru 117855 points

    Cynthia Crutchfield said:
    Verification failed: Values at address 0x000000000003F800 do not match

    Firm/I do not use that device - nor Uniflash - and I have a "different take."   (how delightful)

    You both appear to be sensing a possible, restrictive, programming condition - impeding that process.  

    Might it be - instead - that the memory sector in question must be pre-initialized to accept your, "special data?"   Or - perhaps that "high memory" IS used by the MCU for certain tasks, record-keeping - thus "resists" your addition into that (sacred) space.  (we've some ARM MCUs (from others) where "CKSUM" was generated w/in such "regions")  

    Now you identify the (exclusive) use of Uniflash.   Might Uniflash cause or create this issue?    That should be tested - should it not?

    Perhaps this approach warrants consideration...

  • 0 in reply to cb1_mobile
    Expert 1335 points

    Hi cb1,

    Thanks for chiming in on my problem.  Interesting question.  If I call:

    error= FlashProtectSet(0x3F000), *);

    error= FlashProtectSet(0x3F800, *);

    where *= FlashReadWrite, FlashReadOnly, or FlashExecuteOnly

    all will return with an error=0, EXCEPT for *=FlashReadWrite at address 0x3F800, which leads me to believe that the final 2K block of flash can't be written to.  However, I can't find that specified in the data sheet for the part, AND there is some memory at the end of the previous 2K block, starting at 0x3F000 which I also can't write to.

    Cindy 

  • 0 in reply to Cynthia Crutchfield
    TI__Mastermind 22640 points
    Hello Cindy,

    I created a 32-bit bin file with values 0x12345678. Using Uniflash, I erased the entire flash of the DK-TM4C123G board (which has the device TM4C123GH6PM - same Flash and SRAM size). Then I programmed this bin file to address starting from 0x3F800. Uniflash did not report any errors.

    To verify, I read back the entire content of the flash using "LM Flash Programmer" (different tool) into a .bin file. I opened this .bin file using hex editor. From location 0x3f800, the next 4 bytes have values 12, 34, 56, 78.

    So clearly, I am able to write to 0x3f800 location on a device that has the same flash size.

    Have you tried this experiment on multiple devices - not just one device?

    Are you erasing the entire flash before programming? As a test, before programming to 0x3f800 location, can you read back the flash contents into a binary file and ensure that the flash is erased?

    While configuring Uniflash are you using the correct device name? You can also try to use TM4C123GH6PM and see if that is causing an issue. I did try setting Uniflash configuraion for TM4C1231H6PZ (the device you are using) and still was able to write to the location 0x3f800.

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Guru 47900 points

    Stellaris Sai said:
    So clearly, I am able to write to 0x3f800 location on a device that has the same flash size.  

    We don't doubt that Sai - yet would not the analysis benefit from more of an, "Apple to apple, comparison?"   Our poster may well be including other data - aimed at lower MCU locations - which is suggested by her "limitation" of just 32 bytes for this "high-memory" region.   At minimum - this is a better approximation of her "real world" application.

    My sense is that your success occurs w/"only" a 32-bit binary file - by itself - programmed into the flash high region.   That's a more limited use case - is it not - and as such may not fully resolve poster's issue...

  • 0 in reply to cb1
    TI__Mastermind 22640 points
    Cb1,
    I understand (now) and agree with you. This issue might not be as simple as I initially thought it to be. Thanks for pointing it out clearly.

    Cindy,
    It would be useful to know the different memory regions that were written, before programming the last 2K block, so that we can try to recreate a similar environment that is causing the issue.

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Guru 47900 points

    Sai,

    I think this "Sai" writing NAILS IT!   Usually - the more general the solution - the better, more flexible/extensible and safer the solution...

  • 0 in reply to Sai Reddy
    Expert 1335 points
    Hi Sai,

    The fact that FlashProtectSet() fails for the block starting at 0x3F800 for FlashReadWrite indicates (I think) that the block is not write accessible. The contents of the flash at 0x3F800 and above is 0xFF. I've never been able to alter it and that is, I assume, the initial factory setting. Also, the fact that the Uniflash AND my code both are unable to write to that portion of memory makes me believe that it's not a Uniflash issue (though I did check that the device setting of the Uniflash is correct). Yes, I've verified this behavior on multiple devices (all of type TM4C1231h6pz). I'm thinking this behavior is specific to that chip type- would it be possible for you to check this in your lab with my specific part? Just running FlashProtectSet(0x3F800,FlashReadWrite) would verify the problem.

    Thanks,

    Cindy
  • 0 in reply to Sai Reddy
    Expert 1335 points
    Hi Sai,

    My code is written in the top 41% of the flash (0->0x1ACC6). Prior to attempting to write the 32 bytes to 0x3F800, I wrote those 32 bytes successfully to 0x3F000.

    Thanks,

    Cindy
  • 0 in reply to Cynthia Crutchfield
    Guru 47900 points

    Cindy,

    Cynthia Crutchfield said:
    My code is written in the top 41% of the flash (0->0x1ACC6).

    I'm (perhaps others, too) lost!   What constitutes, "top 41%?"

    If your code starts at/around address 0 - and spans as you note - is not that the "bottom" (lower 41% region) of the flash?

  • 0 in reply to cb1
    Expert 1335 points
    Yes, of course. Incorrect wording on my part. Lower 41% is accurate.
  • 0
    Guru 27665 points
    Cindy, have you tried programming the entire flash at once rather than in two cycles? Also have you tried erasing the whole chip and just programming the 32 bytes at the end?

    It's not clear whether you have or not. And if you can duplicate the error with just the 32 byte file in a freshly erased device it reduces the complexity.

    Robert
  • 0 in reply to Cynthia Crutchfield
    TI__Mastermind 22640 points
    Hello Cynthia,

    I have tried to reproduce the issue that you are facing but so far have been unsuccessful.

    I have used binary files of three different sizes - same size as the one you mentioned, bigger (about 150KB) and smaller(about 85KB). Then I wrote to different location on the upper 2KB - 0x3F800, 0x3F850 and 0x3F900 - and so far the write to upper 2KB has not failed.

    I am wondering if this behavior is specific to the binary file you are using. Can you post the binary file, so that I can try to recreate the issue? If you don't want to post on the forum, you can send it directly to me.

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Guru 47900 points

    @Robert - Once more - we think alike mon ami.   However - I'm quite sure that the "mini write" you suggest was tried - and worked by Stellaris Sai!   (where have we (past) heard/seen that neat prefix?)

    @Sai - (cb1 switches to full "diplomatic mode" (if that's ever possible) - Das ist wunderbar!   (your seizing upon the "specific binary file" she employs.)   This reporter does not believe that will "prove the case" - yet the logic of the method cannot be denied...

    I'd like to see (both) methods blended - she loads only a very small - known good binary file - into the "danger zone!"   Inviting MORE variables (i.e. ANY Variables) into this mess is clear violation of KISS - and users who so violate - deserve their fate!  (or worse!)

  • 0 in reply to Sai Reddy
    Expert 1335 points
    Hi Sai,
    I've solved my problem but I'm not sure what the solution means. I ran the unlock utility on Uniflash, then went through the same programming sequence as before, and now I can access the flash at 0x3F800 normally. The initial programming of the microcontroller was done in manufacturing using LMFlash programmer across a serial line. Do you think something might have happened in the initial programming to cause the error?

    Thanks for your help,

    Cindy
  • 0 in reply to cb1
    Guru 27665 points
    cb1, I suspect Sai tried it but maybe not Cindy.

    I also agree the specific binary is worth checking although I doubt it will prove to be an issue.

    My suspicion lies with process at the moment and if Cindy can write the 32 bit file into freshly erased flash w/o the main application that would go a long way towards confirming that as a suspect.

    Robert
  • 0 in reply to Cynthia Crutchfield
    Guru 27665 points
    Do they set the protection registers?

    Robert
  • 0 in reply to Robert Adsett
    Expert 1335 points
    No- LMFlash programmer is pretty crude when using a serial connection. I just looked at it and basically you give it a binary and that's it. I'm wondering also if maybe we received the microcontrollers in a default state that denied access to that portion of flash. I'm going to try to get my hands on one of our earlier boards and repeat the testing. The only strange thing with this line of thought is that there was a portion at the end of the previous 2K block of flash that I was also not able to access (writes to the region via Uniflash would return the same error). I would have thought that if it was a protection register issue, the problem would only exist in discrete 2K blocks. It's an unsettling problem.

    Thanks for the feedback Robert.

    Cindy
  • 0 in reply to Cynthia Crutchfield
    Guru 117855 points

    Cynthia Crutchfield said:
    initial programming of the microcontroller was done in manufacturing using LMFlash programmer across a serial line.

    That's a "high risk" method - is it not?   And it's being used by manufacturing/production - why is that?

    Serious (proper, focused, comprehensive) programming tools & methods exist.   One you (or others) have chosen appears (not quite) ready for prime time...

  • 0 in reply to Cynthia Crutchfield
    TI__Guru**** 244440 points
    Hello Cynthia,

    Based on the forum thread information and discussion with Sai, it seems that the device may have protection bit set at sometime before the download. The Unlock sequence brings the device back to factory state (returns the protection bit back to 1) allowing for the download of the code bin to the higher flash locations.

    Since the issue occurred above 0x3F800 it seems that 2 blocks were write protected. The process of protection is a two step process if it has to be committed. So accidental programming may be ruled out.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1335 points

    Hi Amit,

    I agree with your assessment and I now know how to fix the issue if it arises in the future.  I plan on checking the next batch of boards before and after manufacturing does the binary download to see if I can pinpoint how the bit might be getting set.  Thanks, as always, for your feedback.

    Cindy

  • 0 in reply to Cynthia Crutchfield
    TI__Guru**** 244440 points
    Hello Cindy,

    If it happens the next time, the first thing to check is the FMPPE and FMPRE registers. If the value in the register are all 1's then the Program-Erase-Read should be available. However if any bit is 0 then one of the actions may fail. If all bit's are 1 and the failure manifests then please do post on the forum.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1335 points
    Will do. Thanks Amit!

    Cindy