Matrix user forums

Hi

Please Help I think I'm missing something simple here
Every time I have a checksum error my pic freezes even after I made some escape codes to reset the pic.
Any Ideas for improvement will be greatly appreciated

Hi. I cant see any reason this would crash your chip other than possibly the interrupt reset causing problems. I don't know why this would be the case, but can't see anything else off-hand that would cause your code to hang.

I have modded your file a little to make the interrupt reset unnecessary. Also you were using a divide operation (% 256) in a loop to calculate your checksum when an AND (& 255) would do.

I would always provide some indication your program is running, for example a flashing LED. if you have an LED array or a similar kind of output, outputting different values to this at different parts of your program helps find out where things are getting stuck.
Good luck.

Jonny

Hallo JonnyW


After a long search I've noticed the following Warning message.
If I disable the RS232 (1) Macro to send the 84 bytes the message disappear.
Could this be the reason for freezing the pic?

Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
main and Task(s): hw used:4, exceeded by:0
interrupt: hw used:5, exceeded by:0

Serious Warning: Possible sw stack corruption, function 'delay_us' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Memory Usage Report
===================
RAM available:368 bytes, used:167 bytes (45.4%), free:201 bytes (54.6%),
Heap size:201 bytes, Heap max single alloc:95 bytes
ROM available:8192 words, used:542 words (6.7%), free:7650 words (93.3%)

Hi. Ah, yes, this will cause issues! They can be unpredictable too.

I believe you can enable software stack: http://www.matrixmultimedia.com/mmforum ... ack#p38548

This will allow you to call deeper than the 8-call HW stack. However, I would suggest instead using flags to indicate that data needs to be sent - set a flag 'SendData' in your interrupt and in your main loop act on this flag (if (SendData == 1) SendData = 0 & send_the_data). Interfacing with peripherals in an interrupt can have strange effects even when the call stack is large enough.

Either way, I think you have found the source of your problem!

Jonny

Hi JonnyW

However, I would suggest instead using flags to indicate that data needs to be sent - set a flag 'SendData' in your interrupt and in your main loop act on this flag (if (SendData == 1) SendData = 0 & send_the_data). Interfacing with peripherals in an interrupt can have strange effects even when the call stack is large enough.

I'm not sure if I understand correctly but should this also remove the warning or just prevent it?
Must I replace the Decision (If BYTE_NR = 84) with (SendData == 1) SendData = 0 & send_the_data). to send the data if the flag are set in the interrupt.

Hello. Sorry, I misread your post. You are saying the issue is in the call in Main(), not the RS232 call to send "OK" in the interrupt.

This is surprising as the "OK" call is guaranteed to take more stack (as the interrupt is called off the back of Main()), but if it works then fair enough.

What I meant was to flag the interrupt as 'fired' in your interrupt routine, then consume the data in your main loop: If this doesnt do the job, I would suggest using the SW stack method and see if this fixes your problem.

Cheers,

Jonny

Hi JonnyW

Just to be sure, In main there is a loop that runs 84 times to send the data from BYTE[SEND_NR] out RS232(1)
This is the one "RS232(1)" that If disabled the warning stops.