TMS570LS1224: Clearing the Flag of a System Software Interrupt

Hello Miguel,

The read of the SSIVEC register will give you the vector of the SSI that caused the interrupt but won't necessarily clear the flag. The interrupt flag is cleared by writing a 1 to the associated bit in the SSIF register that corresponds to the vector read from the SSIVEC register. If you don't clear the interrupt flag the interrupt will not be able to fire the second and subsequent times.

how would that work?

How the line should be written??

Thanks!!

oooh okokok

I thought that as the TRM says that just by reading the register the flag was cleared, it was just needed to read the flag. I will test it tomorrow morning and let you know =)

Thanks!!

Hi Chuck

I tested the code with those two lines and everything worked quite good. Nevertheless... after finishing the interrupt, it returns at the beginning of the main, like if the MCU was getting reseted after finishing the System Software Interrupt...

Hello Miquel,

I assume this wasn't the expected befavior? Can you set a breakpoint in your SSWI ISR and check the value in the LR register prior to return? It should be the return point after where the interrupt initiated.

Can you check the SYSESR register to see if a RESET did occur? To be sure, you should read and clear this register at startup so that events that happen later such as this can see the source of subsequent resets.

I have a breakpoint on the interrupt. The flag is cleared in the first line. The value on the register on the SSIVEC:
Sys_SSiVec
00000801
Sys_SSIf
00000001 00000008

When it enters the IR. Then,
Sys_SSiVec
00000800
Sys_SSIf
00000000 00000008

About the reset:
Initial value:
Sys_SysEsr
00002008
Before the interrupt happens:
Sys_SysEsr
00000008
During the interrupt and at the end:
Sys_SysEsr
00000008


Running line by line, after reaching the }, the code jumped to
rtiREG1->GCTRL |= ((uint32)1U << (counter & 3U));
and there is before it crashes.
After that line, it reaches the } of the rti.c and then jumps to another two codes from me, does nothing and then it lands to
resetEntry
b _c_int00

Hello Miguel,

This sounds like a corrupted stack or stack pointer. Can you attempt to watch the values in the CPU registers and in the stack to see if you can trace it down to where the misdirection is occurring?

Also, can you double check the values in the SSIVEC and SSIF registers during the read and clear operation to insure the bits set are what is expected based on the SSI you are using?

I would be happy to do so but... I have no idea how to do that part...
How do I do that?

I already triple checked the SSIVEC and SSIF values. Everything is there is correct...

Thanks!

Hi Chuck

Hope you're doing great

I was wondering if you could explain me how to see the values of the stack to check what is going on or if is easier if I upload you my code...

Thanks!

Miquel,

If you can upload a simple project that demonstrates the issue, I can have a look at it.

4520.Protesis_de_mano_nov_2016.zipHi

I will upload you the code. I eliminated the important information but the code works and has the problem I explained.

Im using the DSP library for the MCU. Thanks!!

Hi Chuck
Hope you're doing great.
I tried 2 things:
1)deleting all the code inside the SS interruption (didn't work, problem persisted)
2)Taking the interrupt line ( systemREG1->SSISR1 = (0x7500 | (0xFF & data1 )); ) outside the GIOB interrupt, in the main.
Here happened something weird. The interrupt occurred BUT after the SSI, the MCU didn't get a reset but no interrupts entered again, like if all of them had been disabled...

What am I missing?

Best regards

Miquel,

I was looking at your code today and I noticed that you do not declare the SystemInterrupt() function as an interrupt service routine. Can you add the statement "#pragma WEAK(SystemInterrupt) prior to the function and then see if it returns properly (note that I am looking at the code that you had sent in your May 15th post. Again, sorry for the delay. We try to handle posts as they are posted, but in some cases we have to move more involved questions or questions that need bench testing to a que that is handled as we get time to address them.

Also, just to be clear, the include paths for the project did not allow me to fully build the project so I still haven't had the opportunity to build and test it due to the complexity of the project provided. There is still a file that isn't linking due to an undefined reference to a file with a path specific to your PC and I haven't been able to locate where this path is coming from even though I have updated all the include paths for the project.

Chuck Davenport said:

I was looking at your code today and I noticed that you do not declare the SystemInterrupt() function as an interrupt service routine. Can you add the statement "#pragma WEAK(SystemInterrupt) prior to the function and then see if it returns properly (note that I am looking at the code that you had sent in your May 15th post. Again, sorry for the delay. We try to handle posts as they are posted, but in some cases we have to move more involved questions or questions that need bench testing to a que that is handled as we get time to address them.

The code is quite the same. The difference is that I removed all the code about the DSP library so it would be easier to compile. But the rest is the same. 

About the pragma... I will test it later today and let you know. 

Don't worry about the delay. I know is not easy. 

About the compilation of the code, the code uploaded on the other is exactly the same but without the DSP library usage. It should compile without problem. 

I test it today and let you know what happened. Maybe that could be the problem...

Thanks!!! 

ok I just added the #pragma WEAK(SystemInterrupt) and didn't work. What is most, the systems starts directly in abort:

And once (don't know why) it reached this point. 

Why would it happen?

**EDITED**

Also, once I click "run" the code starts normally. Then, when getting out of the SSI, it reaches the RTIStartCounter:

Then goes to:

And finally to:

Thanks

Hi Chuck
I thought we were going to use the other post but thats okay

I tried some modifications. I moved the SSI interrupt into the notification file but the problem persisted... even with the pragma

Miguel,

Can you provide another version of your code with the CMSIS Library completely removed. As I mentioned, when I try to compile, it is still searching for CMSIS related content in a path that is specific to you installation. This is even after I update the include paths to the default locations on my PC. I am unsure if there is a hard coded path somewhere in either the project setup or in the code.

Hi Chuck

Here is the code. Take care with this path:

2084.Protesis_de_mano_nov_2016.zip

It should compile without problems

Hi Chuck
I hope you are doing great
I was wondering if you could build the project or if you had problems. I have been trying to solve the problem but... I haven't been successful...

Regards

Hi Chuck
hope you're great
I was wondering if you had any update... I was able to move my deadline to july 6 but I cannot do anything since the whole code depends on this to work properly...
thanks!

Hello Miguel,

I truly do apologize for the delay on this. I have been out of the office a great deal over the past few weeks due to business travel and vacation.

don't worry.
What could be causing that the interrupt is not generated properly? because, if you already ran the code, once the interrupt ends, it goes to abort after going to the RTI start counter. I have no idea of whats going on... I even tried removing the RTI and the same problem was present (it went to abort after getting out of the SSI)
Regards

Miguel,

Terrific!! So glad you were able to solve this. I really do apologize for not being able to address this issue for you. Really, no excuses are acceptable. Hope you now can meet your deadlines and that if issues come again, you can give us another chance to help.

Hi Chuck
Its okay. I have a question... how good are you with the N2HET??? I need to solve some questions there (in a different post of course)
Thanks!

Hi Miguel,

N2HET isn't a strength for me. I can help with simple questions but more complex stuff I have to defer to other experts. Go ahead and post your questions and we will funnel them to the right person to help.