Core halting inhibits the RELEASE IPC status of the ROM memory API functions

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

cross mob
danieleFing_SMH
Level 1
Level 1
10 sign-ins First reply posted 5 sign-ins

Good morning,

I'm SW designer of third party flashing tool. I'm using a programmable tool that permits to use Cortex Debug Access Port to manage the flashing of the TRAVEO2G.
I see a problem during use of ROM API function to flash the device. I need to HALT the base core (Cortex M0+) and then change the Program Counter to execute a firmware that I loaded in SRAM of TRAVEO2G. The FW in RAM can be also an infinite while(1) loop. After I re-started the first core I'm able once again to acquire the IPC but when i execute an API function it is not able to does its job and to release the IPC. From flashing tool i'm polling the LOCK_STATUS register of IPC struct but I see that it's not be released anymore.
The same behavior occurs if the API function of the ROM memory is run by the firmware that I loaded in RAM. The problem depends on core halting before execution of API function. If in my flow of execution i don't halt the first core M0+ the APIs work with blank/virgin microcontroller T2G.

I see the problem on different series of TRAVEO2G and is not specific of the part number, seems specific of  all TRAVEO2G family.

Could you help me?

Thank you in advance.

Best regards

 

0 Likes
3 Replies
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello @danieleFing_SMH ,

Based on the explanation you gave, I understand that you halted CM0+ core initially and then tried to execute the firmware to flash which you loaded on RAM from the host core (either CM4 core or CM7 core, based on the T2G device family which you are using). Is this understanding correct?

Assuming that the above mentioned scenario is true, let me try to explain the reason for not seeing IPC released.

In Traveo II controllers, any flash operation is performed through system calls (or SROM API). System calls are part of boot code and user needs to invoke respective system call with the specified parameters. As you might already know, the system call invocation happens through IPC.

Whichever may be the master triggering the system call, the system calls are always executed in CM0+  IRQ0. So, if you halt the CM0+ core while performing flash operations, then you will end up unsuccessful. I think the observations you see are because of halted CM0+ core.

Thanks,

Kavya

0 Likes

Hello Kavya,

thank you for the aswer.
Yes, I had actually already seen that it is necessary to keep the first M0 + core in RUN mode (running) in order to run the SystemCalls API. This is because the APIs are like interrupts that execute routines and then put in RELEASE the IPC and return it to execute on first core M0+ what it was doing before the SystemCalls started.

In my case I execute the STOP of the M0 + core, then I write in SRAM in my firmware, I change the Program Counter to the starting address of my FW in SRAM and I put the M0 + core in RUN. At this point I am no longer able to execute SystemCalls. Although the FW I loaded into RAM is an infinite loop (while (1)) which does nothing.

The SystemCalls executed after the core has been stopped and restarted no longer return back the IPC in RELEASE state.
If I execute the SystemCalls in the FW that I load in SRAM I can tell you that a HardFault is generated.

This is a problem to note because the procedure of putting the core M0 + in STOP (halting) is used to re-flash the TRAVEO2G device preventing it from executing the FW contained in the Main Flash during the flashing cycle.

Is there a problem with putting the core in STOP while running the Traveo2G BootROM firmware?

 

Thank you in advance
Best Regards

0 Likes
Kavya_B
Moderator
Moderator
Moderator
100 replies posted 10 likes given 25 solutions authored

Hello @danieleFing_SMH ,

Sorry, but there are still certain things which are unclear/confusing in your explanation.

You stated, "In my case I execute the STOP of the M0 + core, then I write in SRAM in my firmware, I change the Program Counter to the starting address of my FW in SRAM and I put the M0 + core in RUN."

What did you mean by 'then I write in SRAM in my firmware' specifically? Did you mean after stopping CM0+ core you write while(1) loop in SRAM and then change the PC of CM0+ core to that piece of code in SRAM?

From where are you invoking the system call to write to code flash? From SRAM? You mentioned if you do so, you will end up with hard fault, right? Could you please let us know the details on the kind of hard fault you got in this situation. Maybe, you could share the Arm registers showing the fault status registers with us.

If not SRAM, from where are you invoking the system calls from?

Below are certain things one need to consider for successful system call implementation. I assume you might be aware of this and considered this already. But just repeating if in case you missed it:

Please make sure you have done proper interrupt mapping as suggested in '14.1. How can I check if IRQ0/IRQ1 is configured properly, if SROM API or System call is not working?' in Traveo II FAQ. Below is the link for the same:

https://community.infineon.com/t5/Knowledge-Base-Articles/Traveo-II-Automotive-Body-Controller-FAQ-B...

 

Another important thing to check is during the procedure you explained, if the control has successfully reached to entry of the system call or not. Could you please check on the debugger if it reaches to beginning of CM0+ IRQ0 interrupt handler when you invoke the system call?

 

Thanks,

Kavya

 

0 Likes