TM4C123GH6PGE Does not have the correct Memory Map

[dcomer]

I am using a TI TM4C123G Development board (version 1.0) that has a TM4C123GH6PGE chip (not sure of the exact Revision of the processor). I was trying to understand an issue with the SysTick. Bringing up the Hardware Register, the address of the NVIC_ST_CTRL register, reads address of this the ST_CTRL register = 0xc001C010, The datasheet for this processor  indicates the address should be 0xE000E000. Furthermore, the Tiva.xml file that is created by the project indicates the following:

<McuID>TM4C123GH6PGE</McuID>

and later,

<Value>TARGET_IS_TM4C123_RB1</Value>

As far as I know the memory map has not changed across the DIE revisions, so, that seems correct. I’m wonder if the BSP had an incorrect memory map? Can you help me with this? Also, where are the BSP packages installed. Maybe I can fix it locally if there is an issue?

Thanks,

Dave

VisualGDB version: 5.2R9 (Build 1452)
BSP Version 2.1.3.156r2
TI Board number: BD-DK-TM4C123G-1.0

[support]

Hi,

Thanks for reporting this, looks like our bug. We have fixed it and released an update to the Tiva package.

Please update via Tools->Manage VisualGDB Packages.

[dcomer]

Thanks You. By the way, I did figure out where the definitions were. I’m sure you fixed it all, but just wanted to mention, pretty much everything in the 0xc001.cxxx memory space were incorrectly mapped. I will download your update and test. I’ll let you know if I see any other issue.

 

Dave

[dcomer]

One bug did pop up when I reloaded. After successfully re-loading the update, the application is hung on the “Manage VisualGDB Packages” dialog. By hunk, I mean I cannot close the dialog due to a hidden window preventing any action with the “BEL” sounding. I’ve looked at all windows behind (Alt_TAB) and there is not indication of another active dialog.

 

Dave

[support]

Hi,

Yes, the problem occurred because our register parsing was confusing offsets and absolute addresses. We have fixed that.

The window bug should be fixed in v5.3 Preview 2 (or you can simply restart VS and run the update again).

[dcomer]

Hello again (or que Pasa as we say in this part of the world):

 

I believe I found another register error. The TM4C123GH6PGE has 6 16/32 and 6 32/64 bit timers. The register map has 8 16/32-bit timers(TIMER0-TIMER7) timers listed and should have only 6 (TIMER0-TIMER5). The invalid timers (TIMER6 and TIMER7) are mapped into undefined memory (or at least, unpublished).

Thanks for your help!

Dave

[dcomer]

Looks like the RCGCTIMER register needs updating as well. There should only be bits R0-R5 defined where there are now 8 bits; R0-R7.

 

Dave

[support]

Hi,

Unfortunately this is a bit tougher one. As TI does not ship official register definitions, VisualGDB gets them from parsing the header files and this mechanism is not as precise as parsing a machine-readable definition. Currently our parser uses common register definitions for the entire device family and does not remove registers that are not available on all devices.

Unless this causes some serious issues (e.g. disrupts program flow due to collision with some other registers), we recommend simply ignoring the extra registers.

[dcomer]

Hum, I would have thought the datasheet for the specific part was the source, which does show the timer register definitions for a specific part (with respect to the question I have). That said, I suppose that would mean you guys would have to have resources to monitor all device datasheets that VisualGDB  supports and update files for the individual revisions. Compilers such as Rowley’s CrossWorks for ARM does this in their BSP’s. So, I would hope that your guys would become successful enough to a) Have that expertise in-house, or, b) successful enough to have a relationships with the various manufacturers TI to foster inside support in this respect.

Don’t take this as a complaint/criticism. Just a thought process I am going through on how I resolve other issues that come up similar to this. VisualGDB a far better tool than, say Code Compose, to program in (my opinion). Rowley CrossWorks is great, but I still like VisualGDB better in terms of user experience.
Dave

[support]

Hi,

This is actually a matter of price/value. There are indeed products like CrossWorks and Keil that ship detailed and accurate register definitions for all devices, while providing much more basic IntelliSense and debugger experience. VisualGDB instead focuses on usability features that apply to all device families (like advanced IntelliSense or real-time watch), while relying on the device manufacturers’ definitions for hardware registers. This works very well for most of the families (most vendors provide either machine-readable definitions in the ARM SVD format or machine-generated header files that we parse).

Unfortunately TI devices are somewhat of an exception – their header files seem to be hand-edited and they don’t ship machine-readable definitions under a license that allows reusing. Also as their market share is relatively low (below 3% among our users), any feature that will add value to all device families will always get higher priority for us than resolving minor glitches in TI definitions (major bugs like the one you mentioned before are a priority).

If you are a licensed user of Keil or CrossWorks, you might be able to convert their register definitions to a format that VisualGDB supports for your own use (please double-check check their license terms to be sure). If you decide to go this way, we can provide step-by-step instructions on locating/replacing VisualGDB register definition files.

[Author]

Posts