TMS470PLF111

In your last post you mentioned you are a student. I don't understand why you are choosing a EOL'd device for learning.  This device is more than 25 years old. If you want to learn how MCU works, there are many choices with rigorous software collaterals and EVM plus the support. TM4C Tiva MCU has been used by universities in their courses for embedded MCU. It will be something for you to look at. I can't answer many of your questions here as I don't have experience with this EOL'd device. Each time to answer your question, I had to study myself on how they work and search for internal documents that no longer available on the public. In your very first post, I already said we can't support this device on e2e.  Out of good will, I try to help you but I believe our resources can be better spent on existing products.  Please consider other MCUs that have experts to assist you. I will be able to assist you in TM4C Tiva MCU. If you insist to use this device as your learning vehicle, I can no longer support and you will be on your own, sorry. 

Ok, yes it is because it is a processor controlling my trucks BCM, and I have no way to replace the processor with a newer one, unless you reengineer the BCM. I wanted to add remote start to it. And in the process thoroughly learn arm7 and touch base on embeamed systems programming. I thought it would be a fun project to work on while in university. Rather than a dev board modifying just LEDs, number boards etc. 

I have to much invested to abandon, and really appreciate all your help. I am very close and made some successful changes to the original code to suite my needs.   

If it isn't to much to ask is there a more detailed F05 flash module and systems register manual for the TMS470PVF24xB/34xB, other than what is in the TRM, that you already gave me. I found very detailed TI specific manuals for the flash and systems registers but they are for TMS470R1 that is very different it seems. 

Thanks -Jamie   

Jamie Groeneweg said:

If it isn't to much to ask is there a more detailed F05 flash module and systems register manual for the TMS470PVF24xB/34xB, other than what is in the TRM, that you already gave me. I found very detailed TI specific manuals for the flash and systems registers but they are for TMS470R1 that is very different it seems.

If you read the device part number conventions, see below, it belongs to a Platform Architecture. This is the same platform that TMS470PLF111 and TMS470PVF24xB/34xB are based on. In another word, the TRM will be the same. The difference will be the individual datasheets. Different variants of the same platform family may have or not have a specific component or number of instances of a component can vary let alone the different memory sizes among them. TMS470R1 architecture is from an even earlier generation of MCU. You may find similarity when reading the user's guide of a particular module like the Flash or System module but they are not the same. You cannot rely on TMS470R1 TRM for TMS470PLF111. Those register fields that appear in TMS470R1 TRM are no longer applicable to the platform architecture.  

Great I feel more confident in the TRM you have me then, just wish it had more detail. I can't get a positive unlock level 2 message at FFF87108, should have bit 15 set. Even though I am 99% sure I have the correct keys. 

I do not care if I loose all the data, is there a way to do a factory reset or erase all, to reset the key to default all 11111111s or all FFFFFFFs ? 

Again, I am so sorry it's such an old device and would love any help!

What are the four protection keys from the last 4 words of the first 8k sector? See below. 

In the TRM, it says they are default to be all ones after a virgin device shipped. However, you already have an existing firmware in the device. How do you know if the four keys still remain as all ones? Perhaps, the firmware owner has already changed the four protection keys to prevent from altercation. Unless you know what is changed, how would you know what values to write to FMPKEY registers? Let's suppose the previous firmware owner changed the keys to 0x12345678......., unless you know this value, you cannot just write 0's into FMPKEY as I see you do in your code sequence. 

6.3.4.2 Four-Word Protection Keys
Unlocking of protection keys is implemented by the following Flash API function:
• Flash_Match_Key_B
If this option is present, the CPU reads the four stored protection keys out of the flash bank one at a time and
into a register in the flash module. After the CPU loads each key from the bank to the control logic, the CPU
must load an identical user key into the FMPKEY control register. The CPU must load and match all four keys
before any program or erase command can be sent to the flash module.
To enable the module for programming, the CPU must load each stored key value from the bank to the control
logic by performing a normal read access to one of the four protection key addresses in the flash module.
The CPU must then load the matching user key value into the FMPKEY register. This process is repeated
until all four keys are loaded and matched. The control logic monitors which keys have been matched, so the
CPU cannot gain write access until it loads and matches all four keys at least once without any intervening
mismatch.
If the CPU writes a mismatching key at any time (that is, if the user key does not match the key that was most
recently loaded from the bank to the control logic), then all key match states are cleared and the CPU must
reload and rematch all four keys again to gain write access to the module. This feature can be used to disable
write access after programming is completed.
After the CPU has successfully loaded and matched all four keys, flash write access is enabled and the
PROTL2DIS flag (FMBBUSY.15) is set until either a device reset occurs or until the CPU writes a
mismatching key to the FMPKEY register.
To store the key values, the CPU programs the key data into the bank by performing normal program and
erase operations on these four protection key addresses. The key values are stored in the bank as ordinary
data, so the CPU must provide the correct keys before it can perform any program or erasure of the key
values.
When a new device is delivered to the customer, the keys will be all ones, so keys of all ones should be used
to enable flash writes for the first time. Once the keys are changed in the Flash bank, the CPU must
deliberately write a mismatching key value to FMPKEY in order to disable further programming until the new
key values have been loaded and matched. In other words, the flash module remains enabled for the
remainder of this programming session even though the keys have been modified in flash.
The difference between flash protection key read accesses and other reads is that the key data does not
propagate to the CPU data bus until the correct keys are written and the user has taken all required steps to
gain programming access. This is intended to prevent unauthorized discovery of the stored keys by reading
them out through the CPU. Only a user who already knows the keys can gain access to them.

In your below code sequence, you seem to be writing 0. How do you know what is stored in the last 4 words of the first 8kB flash sector is all zeros?

PEEK 1FF0 //dummy read first flash key
PEEK 1FF4 //dummy read 2nd flash key
PEEK 1FF8 //dummy read 3rd flash key
PEEK 1FFC //dummy read 4th flash key
POKE FFF8710C 00 //write 1st flash key
POKE FFF8710C 00 //write 2nd flash key
POKE FFF8710C 00 //write 3rd flash key
POKE FFF8710C 00 //write 4th flash key

Yes, well I seem to be able to read everything on the target all registers, ram, flash etc. just not ECC. Using a usb j tag device. Not sure how he has implemented that, but it seems to circumnavigate the built in flash protection? But only for reading? I cannot use his program to erase the chip, he says that it is due the it being "locked on level 2 flash" And also asked me to find the Global control bit 4 register. I believe ECC is flat out disabled, and that's fine I don't think I need it for anything. 

So with the dump from his program I compared it to the bin file that I wrote to it before it got bricked and they are identical. Also previously I used VPW class2 to read out the entire flash contents, which also is identical except, the function I added before it bricked its self. 

The dissembley of the kernel uploaded by the working VPW class2 kernel shows that it reads the keys from 0x00001ff0, which I think is the last 4 bytes of the first flash sector as, well so this makes sense. The kernel dummy reads from   0x00001ff0 four times adding 0x4 each iteration. Then writes the keys from ram, location 0x080006c6, which is blocks of zeros from what I can tell. Then the kernel writes these to 0xFFF8710C, which all makes good sense. 

Here is a snippet of the bin file showing address 1ff0 the entire row is all zeros. 

See above disassembly, r4 = 0x00001ff0, and r5 = 0x080006c6, r7 = 0xFFF87000, r6 = 0x10c, prior to this loop. I do not trust the simulated C code, because it is adding only 0x1 to the pointer, but the arm7 actual code shows the real truth that it's adding 0x4 (4 bytes) that makes more sense.  

Since I have the entire flash dump, anywhere else I could check for possible key locations? Or is 0x00001ff0 the only one used for architecture TMS470P.  

There is an extremely detailed F035 flash manual and C library for F035 flash, with hal cogen support and  SPNU493E manual. I'd love to find this for the F05 flash. 

Jamie Groeneweg said:

I'd love to find this for the F05 flash. 

The SM470R1B1M-HT is an active device which uses F05 Flash (from a quick look at the SM470R1B1M-HT datasheet). Flash API Modules (Rev. B) is the download link given on the https://www.ti.com/product/SM470R1B1M-HT product page, so that might be of use for your TMS470PLF111. The spnc031b.zip download contains a Install_TI_ELF_F05a_v1.01_FlashAPI.exe installer, but haven't yet installed it to look at the contents.

Also found TMS470R1x F05 Flash Reference Guide which might help