program hang up at "print..string" , same working on other positions and also was working before - have no idea anymore

[AScha.3]

breakpoint reached normal;

from here this jumps to "show.."

and then this breakpoint seems never reached, but when going step by step

line 1354 is reached and also the following "sprintf.." , but it gets curious:

when "Radio.." text is selected , is drawn on TFT and program runs on,

but when"PLAY..." is selected, it never prints and "hang up" in some loop around DMA-INT-busy-ready-DMA...endless. but no hard-fault coming, just busy looping.

+ i did something...probably...because some days before all this working without any problem (since many weeks) and i changed nothing here. just i made some "improvement" in grouping the "chars" and "uint8" together, just for better clarity.

and then tried to improve the ESP web radio program, (-> Radio-ESP active);

just today i found the other "play" hanging up...

i would be happy with any idea, whats wrong here now.

just...this is the asm here:

[Tesla DeLorean]

How deep is the string TempChar ?

[AScha.3]

should be much bigger than ever needed (tft can show 64 char in smallest size)

i am not shure - but i think, the problem is not here:

• it was working before
• nothing different to the other "if" decision, that works still and goes same path

different is: for this "play.." the dma circle loops load from SD card and this is started also;

so maybe , something happens just because of timing, the dma callback wants to read from SD and something goes wrong - the problem is, all this was working before, many hours without pause and many weeks in use;

and i cannot catch it with the debug so easy, because at that point, if try step by step, the debug stays busy - never goes to next line. and on "pause", it shows dma-int-something, but no hardfault. so...even with debug, i dont know, why now this happens.

(and yes, i know, i did something wrong...)

[AScha.3]

next i found: on no more working "play.." data is read from SD card, the header is read correct, so seem no problem there; next is reading data for the output dma buffer, callback, but a breakpoint here is never reached; because no hardfault , only a higher prio INT could do this, i assume - or what else ?

just try to see the INT: seem to be the "right" one, ->HAL_DMA_IRQHandler , but in debug stepping it jumps over the > if(IS_DMA_STREAM_INSTANCE...< and jumps back just to begin again , but it should find the "HAL_SAI_Transmit_DMA(&hsai_BlockA1, ..." i start at setup. how i find the reason ?

[ONadr.1]

What if the DMA in the background exceeds the boundary of its buffer and overwrites the part with other variables. This could only become apparent after regrouping the variables.

[AScha.3]

jep, seems unlikely, because (all same settings) playing the other source - plays without any error.

but i tried to put the "char" arrays back to positions as been before, but still same, no change.

also cpu run at "speed", optimizer -o2 and caches ON ; switch D-cache OFF : no change.

so probably also nothing wrong with my "cache management" (SCB_CleanDCache_by_Addr ... etc.).

if stepping in the print-to-TFT :

but is there:

I am at a loss.

[AScha.3]

see in the dma-int , where it loops around:

when selecting the source->

hdma->Instance is 40020028 (dma1 stream 1 ) , when working input (ESP..) selected,

but is 40020000 , when not working input (play...) is selected, and loops around then.

40020000 is just the base adress, no valid channel - but why this happens ?

[AScha.3 · Accepted solution]

ok, seems i got it. 8)

by commenting line by line backwards from the point of no return...

it happend after the first (successful) file read. it gives back "readed" bytes - in an UINT pointer (whatever this should be).

i used a uint16 for this ...no problem. but in my attempt to write the program more clean, i put this variable declaration in another position . and now, after many hours, i found the beginning of the problem here - so i tried: make it an uint32 , and voila, no more mysterious "hang up".

that's one way to waste time ...