Nov 20, 2020
07:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 20, 2020
07:01 AM
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.
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
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.
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
- Tags:
- IFX
26 Replies
Nov 23, 2020
12:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 23, 2020
12:21 AM
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
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
Nov 25, 2020
01:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
01:47 AM
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
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
Nov 25, 2020
02:23 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
02:23 AM
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
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
Nov 25, 2020
05:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
05:35 AM
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
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
Nov 25, 2020
05:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
05:51 AM
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
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
Nov 25, 2020
06:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
06:14 AM
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
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
Nov 25, 2020
06:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
06:58 AM
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?
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?
Nov 25, 2020
08:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 25, 2020
08:18 AM
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").
Nov 26, 2020
02:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 26, 2020
02:48 AM
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.
Do you got any ideas on this one?
Thanks!
Alex
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.
Do you got any ideas on this one?
Thanks!
Alex
Nov 26, 2020
03:52 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 26, 2020
03:52 AM
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
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
Attachments are accessible only for community members.
Nov 27, 2020
05:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 27, 2020
05:58 AM
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.
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.
Dec 11, 2020
06:32 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 11, 2020
06:32 AM
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!
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!
Dec 14, 2020
01:32 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 14, 2020
01:32 AM
Please could you check PROCONDBG,EDM - if you have set destructive debug entry, then CAN and FlexRay operation is affected.
Dec 16, 2020
01:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 16, 2020
01:43 AM
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.
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.
Dec 16, 2020
07:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 16, 2020
07:07 AM
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?
Dec 18, 2020
02:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 18, 2020
02:55 AM
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.
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!
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.
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!
Dec 18, 2020
05:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 18, 2020
05:08 AM
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?
Dec 18, 2020
11:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 18, 2020
11:14 AM
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 ?? ?? ??...
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 ?? ?? ??...
Jan 12, 2021
04:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 12, 2021
04:02 AM
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.
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.
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:
Continuing the execution (2 times stepthrough) results in a trapcontext:
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!
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.
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.
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:
Continuing the execution (2 times stepthrough) results in a trapcontext:
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!
Jan 13, 2021
04:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 13, 2021
04:03 AM
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?
Jan 14, 2021
07:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2021
07:26 AM
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.
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.
Jan 14, 2021
08:37 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 14, 2021
08:37 AM
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.
May 09, 2021
11:56 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 09, 2021
11:56 PM
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?
May 10, 2021
06:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 10, 2021
06:41 AM
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.
May 17, 2021
12:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 17, 2021
12:45 AM
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!
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!
May 17, 2021
04:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 17, 2021
04:47 AM
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.