Code does no longer work when program size increases using mutiplication?

[rob...@hotmail.com]

Hi all,

I have the following strange problem. I am working on the ILI9341 library and the graphics was staring to work but I could not manage to write text to the screen. When I tried that the PIC went haywire and sometimes came into some kind of constant reset state.

By accident I discovered that it had to do with the size of the program. In the program I include a picture. When I do that the program size changes from 5k to 21k bytes.

If I do not include the picture, printing text goes OK but when including the picture the PIC goes haywire again. If I leave out the printing of text and include only the graphics with the picture then all is well.

When I look at the assembly, there is a piece of code used for printing fonts (using pixels) that uses multiplication. If I look at that piece of code in the asm file the code for multiplication is different. In the attached screenshot you see the code that goes wrong on the left and the code that goes right on the right.

Has anybody experience this kind of problem before so having problems with a large program in combination with multiplication (I may draw the wrong conclusion here). 

Any suggestions?

Hopefully it is not a compiler issue :-(

Thanks

Kind regards,

Rob

[Zet Weeh]

Hi Rob

I had the same with a picture and it stoppen when I controller the hardware. The next time it happende again: Mauve static electricity?

I stopped with your program because I knew you were still working on it.  

Greetings 

Peter 

Mijn spreuk: Wees nieuwsgierig maar hou maat. 

Op 8 sep. 2022 om 20:00 heeft rob...@hotmail.com <rob...@hotmail.com> het volgende geschreven:

Hi all,

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/8b0c12cf-3c70-4da6-80f3-1d30264eef9en%40googlegroups.com.

<comparison.png>

[rob...@hotmail.com]

Hi Peter,

Thanks for the feedback, so you had it too. I know you are using a PIC18. I am using a PIC16 so that could not be it. When it happens I also get some random characters on the serial port.

Since it might be a serious issue, I will first finish the library and mention in the code not to use the big picture if you use graphics and fonts. The picture with graphics works fine and graphics with fonts too but not graphics fonts and the picture.

I think my initial thought about the multiplication may be wrong since there are more multiplications used and when I include a big picture you might get big multiplications.

Kind regards,

Rob

Op donderdag 8 september 2022 om 20:17:03 UTC+2 schreef zet....@gmail.com:

[vsurducan]

Rob, can you check also the stack length when pic goes in loop reset?  

[Rob CJ]

Hi Vasile,

It sometimes goes into reset but sometimes it just hangs.It is unpredictable so I assume that it runs somewhere out of a range that it should not.

How could I check the stack length?

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: vrijdag 9 september 2022 07:03
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Code does no longer work when program size increases using mutiplication?

 

You received this message because you are subscribed to a topic in the Google Groups "jallib" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallib/sx0p79J2U-A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qseDr7%2BTah7FDfmX8%2B6p7GuT%3DxKpAPCfDTA1J7r4EpXAw%40mail.gmail.com.

[vsurducan]

Hi Rob, if you look after each compilation to software stack and hardware stack numbers perhaps you may see important differences between numbers when code is ok and not. I've seen something similar near HW stack fill, but this is dificult to debug. It looks like a jump elswere that it shuld...I guess interrupts are disabled in your test code. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB16370E83D82914789B895CE5E6439%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

[Rob CJ]

Hi Vasile,

I do not see much difference in the stack here.

Compiled witout picture:

jal jalv25r6 (compiled Oct 29 2021)

generating p-code

16680 tokens, 581504 chars; 11716 lines; 18 files

generating PIC code pass 1

generating PIC code pass 2

312 branches checked, 0 errors      

1775 data accesses checked, 0 errors

192 skips checked, 0 errors

writing result

Code area: 6645 of 32768 used (words)

Data area: 222 of 4096 used

Software stack available: 80 bytes

Hardware stack depth 7 of 16

0 errors, 0 warnings

Compiled with picture:

jal jalv25r6 (compiled Oct 29 2021)

generating p-code

16670 tokens, 581507 chars; 11716 lines; 18 files

generating PIC code pass 1

generating PIC code pass 2

328 branches checked, 0 errors      

1901 data accesses checked, 0 errors

197 skips checked, 0 errors

writing result

Code area: 22787 of 32768 used (words)

Data area: 229 of 4096 used

Software stack available: 80 bytes

Hardware stack depth 7 of 16

0 errors, 0 warnings

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>

Verzonden: zaterdag 10 september 2022 06:11

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/CAM%2Bj4qsmMr%3D%3DGFDq46Rrz1AfNotbnkN7AxTcy%3DmwDty-eHyNMQ%40mail.gmail.com.

[vsurducan]

Stacks looks good....Can you resize the picture (or even to cut from it) to fit in a smaller memory bank number? I'm saying to cut it bank by bank from 22787 down. You have to catch the bank border on one cut.  If the problem persist no matter the size of the picture, then is not a bank allocation issue but something else...I do not have other idea until I'll play with your display driver. Thx.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB163791FAABFAFE907900DB74E6429%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

[rob...@hotmail.com]

Hi Vasile,

I have an update on this but do not yet know the root cause. I was working on new fonts and I ran into the same issue that the PIC16F18857 was in a constant reset when I included all fonts that I was testing. After some program size (not around a 16k boundary since the program works OK when it is 18k in size but it is not working when it is 21k in size) the PIC goes haywire.

So for the new font sample program I took a PIC18F46Q10 and then everything worked without any problems. In that case the ROM size was around 24k. I also replaced the PIC16 by another one (same type) but that made no difference. So it is either a bug in the chip, but that was not mentioned in the silicon errata sheet, or there is an issue with the compiler. 

Kind regards,

Rob

Op zaterdag 10 september 2022 om 18:00:48 UTC+2 schreef vasile: