Skip to content

Problems with the new Arduino Samd Board 1.8.10 (32bit ARM Cortex-M0+) Version #576

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
CptHolzschnauz opened this issue Dec 15, 2020 · 8 comments · Fixed by #579
Closed

Comments

@CptHolzschnauz
Copy link

After upgrading to 1.8.10 the compiler cant't find #include <avr/pgmspace.h> anymore (File not found)
The whole controller was throttled down to maybe 5% of it's norma speed, everything was working like in super slow motion.
After including the pgmspace.h manually nothing changed, eveything in slow motion.

Then i downgraded to 1.8.9 and everything was back to normal...strange.
I can't give additonal infos, the compiler went trough normal.

@facchinm
Copy link
Member

Hi @CptHolzschnauz ,
this is very concerting, thanks for letting us know.
Can you post your sketch (or a snippet exposing the erratic behaviour) and other info like board in use? Thanks

@CptHolzschnauz
Copy link
Author

Hello, Master of the Core!
I am using a MKR 1400 and my sketch is about 3500 lines. After upgrading to 1.8.10 the compiler can't find the file with #include <avr/pgmspace.h> anymore. So i included it manually (copy the .h and .cpp into my sketch folder and
#include pgmspace.h). After that everything worked like normal (Compiling, Uploading, the Sketch) but the the whole Arduino was working in super slow motion (Like CPU throttled down to 5 %). I did not spend to much time in examination because after a simple downgrad to 1.8.9 everything went back to normal.
The slow motion i saw was mainly in displaying graphics from PROGMEM and with the Adafruit GFX Lib.
I think there is a link between these two events (pgmspace not found, slowdown, NVRAM, Flash ) and something is wrong there.
Thats all i can say for the moment. Tell me if i can help furtherwise, i have a black magic probe here but i need a hint.
Thx for your great work anyway!
With best regards
PS: Please wire the I2S an the MKR1500 like you did on the MKR1400 otherwise the board can't make voicecalls what i desperately need...and they are about to shut down 2G and 3G so the MKR1400 won't work anymore...

@facchinm
Copy link
Member

facchinm commented Dec 16, 2020

Ok, let's try to put together some info:

  • SPI speed calculation has changed between 1.8.9 and 1.8.10 . In fact, some frequencies that were not reached before are now ok. This could be a problem with some hardware.
    From Adafruit_ILI9341 driver, for example, default SPI frequency is 24000000 . With core 1.8.9 we are sending a 12MHz clock, while 1.8.10 produces the correct frequency.
  • Progmem (for samd) is just a wrapper over const char* since the architucture has a unified address space. No performance impact here.

So it would be nice if you could test an example sketch for your display / GFX lib combination.
Reporting here would be enough if I have the same display available 🙂

Thanks

@CptHolzschnauz
Copy link
Author

Salute
I used a MKR 1500 to test and attached the SPI clock pin to my oszi :

First i drew a bitmap on the display out of the progmem (With <Adafruit_GFX.h> and <Adafruit_ST7789.h>):The clock speed went down to around 88 kHz and the bitmap came in very slow motion (Line by line visible with the bare eye)

After that, the sketch plays a sound to test the general behaviour with a heavy system load over I2S (with <AudioZero.h>):
The SPI clock speed rise to around 416 kHz and the sound played normal, everything works fine.

After that, the basic sketch (counting up and down without SPI or anything else) within the loop() works without any issues on normal execution speed. The clock went down to zero (f<10Hz).

The same sketch compiled with 1.8.9: The SPI clock speed stays at around 416 kHz and everything works with high speed without any issues.
Ergo: I think you're on the right track with your assumptions.
Cheers

@facchinm
Copy link
Member

Thanks for testing! With 88KHz do you mean the chip select pin or the actual SPI clock? Beacuse it should be in the order of magnitude of some MHz

facchinm added a commit to facchinm/ArduinoCore-samd that referenced this issue Dec 17, 2020
@CptHolzschnauz
Copy link
Author

You're right...I measured these results at the SPI CLK pin. I'm in the office now so i can check this by tomorow.
The oszi synced to that frequency and i saw the signal flank like normal. Strange. I'll do a crosscheck, it was early in the morning, maybe i saw a . in the chiffre...
But in general, the finding is that the clock speed is going down while communicate with the ST7789.

@facchinm
Copy link
Member

@CptHolzschnauz would you mind testing #579 ? 🙂

facchinm added a commit to facchinm/ArduinoCore-samd that referenced this issue Dec 17, 2020
Fixes arduino#576

From https://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D21_DA1_Family_DataSheet_DS40001882F.pdf , Table 25-2

Syncronous mode (the one we are using) condition is fBAUD <= fref/2 .

Since fref can be as high as F_CPU (48MHz) let's limit the possible fBAUD to F_CPU/2 .
@CptHolzschnauz
Copy link
Author

I can confirm it solves the problem here! Thumbs UP!
Thx for your great work! Wire the I2S on the 1500! And have a good one! ;=)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants