• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 2114 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.

Compiler/TM4C1233D5PM: Firmware compatibility

Christian Steiniche
Intellectual 565 points
Part Number: TM4C1233D5PM
Other Parts Discussed in Thread: TM4C1233H6PM

Tool/software: TI C/C++ Compiler

Hi

This is an easy one :-)

I am currently using a TM4C1233D5PM. I would like to mix in some TM4C1233H6PM (with more flash and ram) from the same Tiva family.

My question is, will firmware compiled for the TM4C1233D5PM run directly on the TM4C1233H6PM ?

My best guess is that it will work. However, I cannot find a source to confirm.

Thanks

Best regards

Christian

  • 0
    Guru 13040 points
    Not really an easy one... But easy to guess.
    When you compile your firmware, a whole memory map is produced.
    Given that your "new" part has more flash and more ram, and that the default base addresses for both parts are (probably) the same, the program will run.
    But, really, do copy the project into a new one, change the properties related to the part number, and recompile. Or, to be more elegant, create a new configuration for the project, with the particular settings for your new part...
    I have run several "wrong" firmwares in different mcu's - most of the time they work when the parts are similar.
    And, of course: CAREFUL with wrong pin mappings!
    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 565 points

    Hi Bruno

    Thanks for your reply!

    Both MCU's are from the same Tiva series cf. below image:

    To my knowledge, these parts are identical, except for the memory. Can anyone confirm that this is correct?

    The reason for the interest in this is that I have several firmware versions released already and I would like these to be able to work with an hardware upgrade using the MCU with more memmory. For future firmwares, I will, naturally, compile to the "correct" hardware.

    Thanks.

    Best regards

    Christian

  • 0 in reply to Christian Steiniche
    Intellectual 565 points

    Hi 

    I would really appreciate if anyone can confirm above.

    Thanks

    Best regards

    Christian

  • 0 in reply to Christian Steiniche
    Guru 13040 points
    Christian,
    Are you not able to test it?
    Did you check pin by pin compatibility on the datasheet?
    As I said, my experience is that firmware written for a smaller-memory-mcu runs fine on a pin-to-pin compatible bigger piece, but really, I wouldn't throw the products out there (or order 5,000 pieces) before at least soldering one into an existing board to confirm...
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    May I second poster Bruno's, "declaration of caution?"

    It may be rare that "normal" users here - have used (both) of the parts you specify - thus any answer carries an element of "risk." And - unfortunately for you - factory crüe may bump against that same (exact) part usage.

    While not the time/effort saving response you seek - procurement & installation of the new device - followed by reasonably "exhausting" test/verification - may prove your fastest method to draw a "real" conclusion.

    The design of an adequate test protocol - which exercises all potential function calls - under all possible timings/settings - (even those believed "rare") adds to your time & effort - while providing greater insight into your mission's success...      Do note that (many/most) large firms  will look w/concern at any such "change" - and usually  "require"  the development of an extensive test suite - which (properly) confirms the adequacy of your new board's functionality...

  • 0 in reply to cb1_mobile
    Intellectual 565 points

    Hi both

    Thanks for your replies!

    I am definitely going to test with both parts.

    However, I would be much more comfortable knowing that it was designed to work (within the same series). As you write, it will be difficult to do an exhaustive test comparing all functionality on both parts.

    I was under the impression that this was indeed the purpose of grouping the tm4c parts into groups (series).

    Best regards
    Christian

  • 0 in reply to Christian Steiniche
    Guru 117855 points
    Thank you - appreciated.

    I agree w/your identified, "Sense of Purpose." Yet - might "reality" add restrictions to so "noble" a goal?
    Is there a difference (maybe) between "in theory, generally, designed to work" versus (often) Cold, Cruel Real-World REALITY?

    One time-saving method - which my firm HAS used w/some success - has you visiting vendor's local office - and asking if they might contact "current users" of your new device - in your behalf. (unfortunately - if you are "not yet" a volume user - such request may not receive full & committed attention. Even then - it proves (still) worthwhile...)

    Most all vendors feel compelled to (sometimes) "over-promote." Thus the (indirect) promise of, "Duplicative Performance - across the same MCU series" - may be an illusion. You may gain (some) comfort by requesting that the vendor "sign off by acknowledging - in writing - such capability." As w/the "claim of security w/in this class MCU" it proves rare (i.e. NEVER) that such a writing will appear. That's perhaps telling - is it not?
  • 0 in reply to cb1_mobile
    Intellectual 565 points

    Hi

    Just an update on this in case someone seeks the information in the future.

    I tested compiling the same code for both TM4C1233D5 and TM4C1233H6 using the same linker file (i.e. limiting the available memory of the H6).

    The resulting binaries seems to be 100% equal. That is, the same code compiles to identical binaries for D5 and H6.

  • 0 in reply to Christian Steiniche
    Guru 117855 points

    Good that - but would not such a test benefit when the "real" available memory is employed?

    And - is that same result (guaranteed) in the future - under newer compiler & IDE versions?      Such should be considered - should it not?

    I recall reading (likely on some ARM forum - yet I suspect NOT here) of an issue which resulted - from a situation very much as you describe.
    If time allows - will try to locate & link - but it was "year+ past" and may not have been logged for review...

  • 0 in reply to Christian Steiniche
    Guru 13040 points
    Christian,
    That was a wise approach. Of course: same binary, same code, surely compatible!
    I understand that your objective was to ensure that you could start populating the bigger chips on your boards without managing yet one more firmware version, so for now you're probably good to go, correct?
    Not sure if I asked, but why did you choose to use the bigger RAM IC now? Is it easier to purchase? Of course, if you plan to actually use the extra RAM, you will need a new firmware...
    Still, thanks for the feedback!
    Bruno