TC223 PFLASH Programming

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello,

I am trying to program a pflash area on the TC223. I already did successful program an area in the dflash. The GitHub Project was a good guide: https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Flash_Programming_1_KIT_TC...

However when programming the pflash I always get stuck with a Protection Error. I already checked a bunch of registers, but I do not see a bit indicating that I am not allowed to erase or write in the pflash, see screenshot below.
4792.attach

I also did use the memcopy operations for the flash commands, to copy them into the SRAM. I was wondering if I should also copy other functions of my code into the sram to not disturb the pflash with reads when trying to program. Do I need to do that although I am programming a different sector where none of my code is lying?

Any guidance is appreciated!
Alex
0 Likes
26 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Alex,

You cannot read and program the same bank of PFlash at the same time - a read will make the Flash go busy while doing the read, and a programming sequence would then get an error (but probably a sequence error rather than a protection error). Likewise, you cannot read the flash when an erase or programming operation is underway. So if the sector is in the same bank, then you cannot do both at once.

The code sequence you run - does it check for the success of the statement or not, i.e., when clearing ENDINIT, is it cleared before the erase command is executed? If you are executing the code from PSPR, then they are loaded and executed quite quickly, so could it be possible that you have written to the SCU (I think....) to disable ENDINIT, but that it hasn't yet completed, hence you get the protection error? If this is true, then a delay between the disable endinit and the erase step would solve it.

Cheers,

Darren
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

I have tried your suggestion with the delay, unfortunately without success. I have also tried the remedy out of the user manual regarding the PROER. I cleared all the status bits in the FSR Register, but the the PROER still gets set on any erase or write operation. The enter page mode and load page commands worked (at least I did not see any flags popping up).

To your first point: In the example mentioned by me I do not see where the code is lying, the controller there seems to have more flash banks. And maybe the code is running of another bank as the flash operation, so the example works. But on my controller I only have one flash bank. So does it mean that I have to copy my whole pflash code into the PSPR? Unfortunately right now I will not be able to do so as my code is much bigger than the 8kbyte I have available in the PSPR.

Is there anything else I could try before starting to throw away most of my code?

Thanks!
Alex
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Alex,

I think the key here is we are getting a PROER (Protection error), not an SQER (Sequence Error), so I don't think that it is a read while doing a flash operation which is causing this particular error. Here is what could be causing a PROER:

* Write page executed on a sector with active write protection, of the flash module has active global read protection.
* Disable sector write protection when the passwords do not match

If the PFlash was busy due to the write, then we would expect a bus error and subsequently a CPU trap. What is FSR.RPROIN set to - 0 in your previous example, but FSR.PROIN is 1, so we have read or/and write protection configured. You also have bit 22 set - WPROIN1 is configured. One of these is likely to be the culprit. Can you run a disable write protection sequence, do your write, then resume protection?

Cheers,

Darren
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

so I double checked. in the FLASH0_FSPRO Register my bits PRODISP and PROINP are both 0.

The user manual is not specific on those bits. Although I assume:
1. PROINP = 0 means that there is no Protection
2. PRODISP = 0 means that the protection was not disabled. But then, how do I disable the protection? Chapter 11.5.5.4 of the manual is not that specific.

Could you please confirm this assumptions?

I also was not able to find the WPROIN1 bit that you wrote about. In which Register do I find this?

Is there maybe a CPU Register that holds the information what caused the PROER? Just similar to some data or address registers when some trap occurs? This would help me in the search.

Kindest regards
Alex
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Alex,

Would you mind letting me know which processor core you have on your board - I'm not totally sure what the TC223 is using. And I appear to be looking at a slightly different register to yourself, so you may not have WPROIN1, and I need to find the right manual!

You can disable protection by running a disable write/read protection sequences. You can run this before doing the load page instructions to upload the data. Your assumptions about the meaning of 0 in both cases is correct. There is no register which stores what caused a protection error - there are only a limited number of cases which can generate it, all other errors tend to generate sequence errors, or the other error types seen in the status register.

Cheers,

Darren
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Alex,

OK, so I now know which manual to look at thanks to UC_wrangler. Do you have any of the PFlash marked as HSM exclusive? This is defined in PROCONHSMCOTP - you would be unable to write to these locations unless you were the HSM initiating the write sequence.

Please can you go through the chapter "Effective Write Flash Protection" and check the values of the registers suggested. It could be that the flash is marked as one time programmable, in which case you can only use the write page once command. This chapter defines all of the conditions which can generate a PROER. So we want to look additionally at PROCONP0, PROCONOTP and PROCONWOP.

Cheers,

Darren
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
So I took a look at the PROCONP0, PROCONOTP and PROCONWOP Registers. They are all set to 0.

I also tried doing a reset to read command to clear the whole FSR Register before doing the flashing. I realized that there is an uncorrectable error which I am not able to clear, FSR.PFMBER. Maybe this will not let me do anything in the flash? But what would be a solution to that? Is my chip already bad/gone?

I have found the Ifx function
void IfxFlash_disableWriteProtection(uint32 flash, IfxFlash_UcbType ucb, uint32 *password)
I do not have any user configuration blocks configured and hence I do not have a password for them. Or am I missing some documentation?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
So you have either a triple-bit error or an address error, which if it is not cleared by the reset to read indicates that it could be permanent. You could disable the bus error by setting MARP.TRAPDIS, which may allow you to do other things afterwards, such as reading the UBAB to see the affected internal flash address (depends on UBABCFG.DIS and UBABCFG.SEL (see section x.5.6.2 "Flash ECC").
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

I guess my board just needed a break, because today the PFMBER is appearing form time to time, but I am able to clear it with the Reset to Read command.

I have been further investigating and I realized that I was unlocking and taking a look at the wrong register for ENDINIT Bit. SCU_WDTSCON0 is the correct one and not the SCU_WDTCPU0CON0. Right now I do not get the PROER bit anymore. Also the Bits indicating a n Erase and Programm are being set. Unfortunately I will still have to investigate why I do not see any data being programmed into my pflash.
4802.attach
Do you got any ideas on this one?

Thanks!
Alex
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Hi Alex,

The erase and program bits being set mean that it has seen an erase and a program operation complete, and their is no OPER to indicate that an error happened during programming, and you didn't get an SQER either to indicate a problem with the sequence. You could do a clear status command after each step so that we can see when doing the commands each one in isolation, i.e. if one of them caused an error, because the bits are sticky, you don't know at the end which command caused it. So the step would be to do the command, read the FSR register, issue a clear command sequence, do the desired flash sequence.

So the programming side doesn't seem to have an issue, there is no obvious reported error. The only other thing is are we sure that when reading the values we are using the correct addresses, and are not somehow reading from elsewhere? I'm clutching at straws at the moment!

Cheers,

Darren
0 Likes
lock attach
Attachments are accessible only for community members.
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hi Darren,

so I do not see any flags being set when stepping through the code line by line.
I attached my code, I tried to keep it as original to the example I mentioned earlier. The designated address for the pflash I am trying to write to is 0xA0004000, which is sector 1 of my pflash.

I will not be available next week, so excuse if I will not be able to answer.
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello all,

an update on what I can see when running my flashing routine of the pflash.
I have found that when I run my pflash programming routine some of my code does not work properly afterwards. For example my can module still works fine, the data is getting send out as it should, but there is no reaction to some digital inputs. Is it possible that I rewrite some code of the processor during my flash routine although I do not see any code lying at my programming destination location?
Did anyone encounter similar problems while trying to Programm the pflash?
Maybe this are some clues to what is going on in the processor?

Any help appreciated!

Thanks!
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Please could you check PROCONDBG,EDM - if you have set destructive debug entry, then CAN and FlexRay operation is affected.
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

no I do not have any bits set in the PROCONDBG. And the can is not the issue as the Can is still working fine. I thought the observation I have made that the processor does not process digital inputs correctly may lead to another clue to what is going on/wrong during my pflash sequence.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Is the processor running using cached addresses or non-cached addresses? Was wondering whether the routine was partly cached and had partly updated, but then saying that you couldn't load into cache from a location being programmed. Going back to the beginning, you are programming PFlash, there is no error reported during the operation, but when read there is nothing at that location programmed. So when you are looking at the location programmed, this is how? The CPU accesses from it, or via a visualisation tool?
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

I am writing my code into the pflash at the locations which the screenshot is showing. Because it is all 0xAxxx xxxx I assume this is the noncached memory. In my code I always use the noncached addresses to write or delete the data and I check the pflash with my debugger ude, at the memory areas that I have programmed.

4839.attach

I have restructured my code, I have separated the delete and the programming of my pflash Index 1 0xA000 4000. Now I see that the write to my pflash is successful. It seems that there are some issues with my erase.

When I let the processor run through the deleting sequence I see that the action in the pflash is susccesful. The values that I have written into 0xA000 4000 are being overwritten by zeros. But afterwards when I try to halt my processor I can see that there is an LEA assembly instruction pointing to a location in my pflash where no code is lying (all zeros). And it just does not move from there.

The strange part is, if I put a breakpoint at the erase instruction of the pflash and step through with the debugger I see the processor returning to its normal tasks and not getting caught up in the behavior described above.

Thanks for your support!
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
I think you will need help from others now, its going outside of my area of expertise! An LEA is load effective address, so it should be trying to load the contents of 0xA000_4000 (or the address in pflash you have if different) into an A register. I don't know or understand why it does not move on, as it does not say execute that instruction. What is the following instruction?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
When you're reading A0004000, is it simply erased, or did you program 0s into it? If you try to load a value from erased PFLASH, you'll get a CPU trap (Data Synchronous Error).

Some debuggers are lazy and just display erased PFLASH as 0s (with an occasional bit set here and there due to ECC algorithm overflows). In iSYSTEM for example, erased PFLASH is displayed as ?? ?? ??...
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren, hello UC_wrangler,

I have taken a closer look and here are some details:

I first program just a few bytes into a sector 0xA000_4000 which I do not use for my code.
4871.attach
This executes just fine.

Afterwards I do an erase using the IfxFlash_eraseMultipleSectors. As a result I do see 0s at the memory 0xA000_4000.
4872.attach
So this also works. But after this erase the controller stops working. No reaction to inputs no communication via can etc. and when I halt the processor it shows that the command which is being executed is this LEA function:
4873.attach
Continuing the execution (2 times stepthrough) results in a trapcontext:
4874.attach
So is this the CPU Trap you described? For me most important is to see that the controller still executes its normal functions (can etc.) after erasing the flash sector as it does after programming the few bytes.

Thank you for your help and I wish you a happy new year!
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
I don't know TriCore assembler at all well. but the highlighted command in yellow appears to have the same address offset at the SVLCX command in the lower snapshot. It looks like the controller is having an issue trying to execute the trap handler and saving the context. Where is it saving the context to?
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello Darren,

unfortunately I do not know how to answer your question. Could you explain in more detail what information is required?
I have checked the D15 Register which contains the TIN. It says 4 which is an Memory Protection Execute. Is there some protection of the pflash when erasing it? Should I include some delay? Because when I step through with the debugger I do not encounter such problems.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
When erasing a flash, the busy bit for the flash bank is set in the status register, and any access to the bank being erased will error. Hence the recommended sequence when erasing a bank is to wait for the busy to go high, then wait for it to go low, and then you can read the erased flash without an issue.
0 Likes
User20114
Level 1
Level 1
alexander.bil wrote:
Hello Darren,

unfortunately I do not know how to answer your question. Could you explain in more detail what information is required?
I have checked the D15 Register which contains the TIN. It says 4 which is an Memory Protection Execute. Is there some protection of the pflash when erasing it? Should I include some delay? Because when I step through with the debugger I do not encounter such problems.

I have the same problem with erasing flash, I was wondering how you solved the problem?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Are you executing from RAM? The most important point is that you can't execute code from PF0 and erase or write to PF0 at the same time.
0 Likes
User20530
Level 3
Level 3
25 sign-ins 25 replies posted 10 sign-ins
Hello,

we actually made some progress in our project, we are not finnaly done, but we are able to delete a whole pflash sector.

The issue was the scheduler in our project.

We used the github example:
https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Flash_Programming_1_KIT_TC...
and modified it to our board. After that I saw that the erase and programming was working fine whilst called in the init (before the main).

Now we know the erase of the biggest pFlash Sector does take up to 180ms at our Controller TC223.

Thanks for the assistance!
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
alexander.bil wrote:
Now we know the erase of the biggest pFlash Sector does take up to 180ms at our Controller TC223.

That's a rough guideline for new devices at room temperature. Note that the datasheet specifies 1000 ms as the maximum erase time.
0 Likes