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.

TM4C1294NCPDT: Error in address range of SRAM in manual(?)

Part Number: TM4C1294NCPDT

Hi,

the TM4C1294NCPDT has 256 kB of SRAM which one would expect in an address region of 0x4.0000 bytes. This is also the case in the .gel file available in CCS where the SRAM region is declared as below to start at 0x2000.0000 and be of 256 kB in size:

GEL_MapAddStr(0x20000000, 0, 0x00040000, "R|W", 0);  /* SRAM */

However, the respective manual shows a different, larger non-power-of-2 range in two places: "0x2000.0000 0x2006.FFFF Bit-banded on-chip SRAM" in Table 2-4. Memory Map and Table 2-5. Memory Access Behavior.

More or less the same was also mentioned here already.

Is this just an error in the documentation or what's else at these addresses? May I kindly request some changes to the documentation in this regard? Thanks.

  • You are correct. It is an error in the documentation. The correct ending address of the SRAM is 0x2003 FFFF.
  • Thanks for verifying that. It would be nice if this error would get corrected (at the two locations I mentioned and probably the bit-banding's end address too). Is there anything I can do to make that happen?
  • Thank you for your input. I have noted your request for an updated datasheet. Unfortunately we currently do not have an update of that datasheet in our schedule.
  • This (current) datasheet error is (another) illustration of, "Known Errors and/or Faults NOT being successfully propagated (thus shared) w/your client-users!"   Predictably then - endless users likely, "Fall to the same trap" due to, "vendor scheduling short-falls."

    Would not a (far) better approach see these, "Known Errors and/or Faults" promoted to inclusion w/in the forum's BOLD, "Top Red stripe zone" - presently reserved for uber important (NOT) "Blogs, Groups, Videos?"

    Would not "Tech UPDATES" serve as a "neutral" title for this valuable listing of issues - which "vendor scheduling" - cannot seem to accommodate?   (certainly not in a timely fashion)

    The apparent "hoarding" of some volume of, "Known Tech Issues" may not best serve your client-users.    Placing those "issues" w/in a, "a Well Marked - regularly updated/expanded, simply accessed file (w/in the pristine "Red-Stripe Zone" atop the forum) likely serves as a (vast) improvement!

    Delaying development - due to the suppression of "Key Known Issues" (often of great need, interest & aid - both to client & vendor-users) is unlikely to insure your meeting (even exceeding) your "Sales Volume Targets!"

    Satisfied & successful client-users - well able (on their own) to note, work-around and/or resolve, "known issues" - seems a (most) worthwhile objective - while (overcoming) scheduling challenges.   (which "hold-hostage" the eased & efficient note of multiple, "Known Issues" - destructive to client-user success...)