RFID-RC522 crash my code

Hello everyone.

I’m using a Blue Pill.

I set up a basic example of RFID using MFRC522. Test with Arduino UNO and it worked. I tested it with STM32 Blue Pill and it worked too.

When I added other components (Display 7 segments, buzzer, leds, shifters … and increased the code) it stopped working.

I disassembled and started with other components, testing everything and writing the code as needed.
When I add the RFID module RC522 the STM32 breaks down. It does not even initialize. (I put a Led that shows when it starts).

I tried to update the RFID library. I downloaded it from the same repository and made it worse. Made mistakes by saying that it was necessary to have C++11.

I tried to go back to an old library and now I get a lot of warnings.

I use a plugin (VMicro) for visual studio and arduino IDE 1.8.2.

(I tried to compile using the two, the problems are the same).

Can someone help me?

GNU++11 was added to the master repo yesterday

RogerClark wrote:GNU++11 was added to the master repo yesterday

Not all libraries are compatible with the STM32 hardware or the Libmaple core.

It sounds like you may need to make changes to the library.

BTW. Does the library work on Arduino ARM boards like the Due and Zero ?

RogerClark wrote:Not all libraries are compatible with the STM32 hardware or the Libmaple core.

It sounds like you may need to make changes to the library.

BTW. Does the library work on Arduino ARM boards like the Due and Zero ?

You could see if it compiles for the Due or Zero, as at the moment it does not compile on STM32.

Re: working 2 years ago.

Why not just download the old version from github if it was working for you, and if you want to help the author make it compatible with STM32, then try some newer versions ( different commits to github) and determine which change broke it.

dmd wrote:
When I add the RFID module RC522 the STM32 breaks down. It does not even initialize. (I put a Led that shows when it starts).

RogerClark wrote:You could see if it compiles for the Due or Zero, as at the moment it does not compile on STM32.

Re: working 2 years ago.

Why not just download the old version from github if it was working for you, and if you want to help the author make it compatible with STM32, then try some newer versions ( different commits to github) and determine which change broke it.

zoomx wrote:
Maybe your module makes a lot of noise that your STM32 board doesn’t like.
Maybe your RFID module take too much power so the STM32 doesn’t boot.

are you using this library?
https://github.com/miguelbalboa/rfid
..Arduino\libraries\rfid-master\src/MFRC522.h: In constructor 'MFRC522::MFRC522(SPIClass*, SPISettings)':

...Documents\Arduino\libraries\rfid-master\src/MFRC522.h:422:20: warning: 'MFRC522::_spiSettings' will be initialized after [-Wreorder]

const SPISettings _spiSettings; // SPI settings.
^


ag123 wrote:are you using this library?
https://github.com/miguelbalboa/rfid
..Arduino\libraries\rfid-master\src/MFRC522.h: In constructor 'MFRC522::MFRC522(SPIClass*, SPISettings)':

...Documents\Arduino\libraries\rfid-master\src/MFRC522.h:422:20: warning: 'MFRC522::_spiSettings' will be initialized after [-Wreorder]

const SPISettings _spiSettings; // SPI settings.
^


assuming that visual studio is using the same gcc/g++ compiler after all, it would either seem that the compilation flags may be different e.g. that there are more warning flags using in visual studio (perhaps -wall?) or for that matter if it is actually a different compiler than the compiler is give more warnings or is run with different flags perhaps.

compile warnings need not necessary result in stalls, e.g. if you run out of memory on the blue pill, there may literally be no warnings or errors during the compile. but still it could crash if there is no more memory.
apart from that, there are too many reasons for a stall could there be a hard fault of some kind? could the sketch be stuck in a loop waiting for data that never arrive (this is fairly likely)? or could the sketch be running a wait instruction in which expected interrupts never arrive? e.g. you have some codes that checks a condition then run WFI (wait for interrupt) and the interrupt occurred between the check and WFI. so when the cpu runs WFI, it just keep sleeping waiting for an interrupt that has already gone (race conditions do happen)

my usual ways i try to diagnose is to *blink the led*, you could literally have a function that blink it differently based on a parameter.
this would give you hints on where it freezes. e.g. if the led did not blink at all perhaps the sketch simply crashed before any statement is run
beyond that there’s Serial.print() to try to diagnose the problem, and if that still did not get to the bottom of it, it may be necessary to run a debug then

just 2 cents,
hope it helps

ag123 wrote:assuming that visual studio is using the same gcc/g++ compiler after all, it would either seem that the compilation flags may be different e.g. that there are more warning flags using in visual studio (perhaps -wall?) or for that matter if it is actually a different compiler than the compiler is give more warnings or is run with different flags perhaps.

compile warnings need not necessary result in stalls, e.g. if you run out of memory on the blue pill, there may literally be no warnings or errors during the compile. but still it could crash if there is no more memory.
apart from that, there are too many reasons for a stall could there be a hard fault of some kind? could the sketch be stuck in a loop waiting for data that never arrive (this is fairly likely)? or could the sketch be running a wait instruction in which expected interrupts never arrive? e.g. you have some codes that checks a condition then run WFI (wait for interrupt) and the interrupt occurred between the check and WFI. so when the cpu runs WFI, it just keep sleeping waiting for an interrupt that has already gone (race conditions do happen)

my usual ways i try to diagnose is to *blink the led*, you could literally have a function that blink it differently based on a parameter.
this would give you hints on where it freezes. e.g. if the led did not blink at all perhaps the sketch simply crashed before any statement is run
beyond that there’s Serial.print() to try to diagnose the problem, and if that still did not get to the bottom of it, it may be necessary to run a debug then

just 2 cents,
hope it helps

Sounds like the SPI class is may being correctly initialised under Visual Studio

Although there are a few people who use the LibMaple core with Visual Studio, the Core (LibMaple) is only designed to work with the Arduino IDE and then only specific versions of the IDE.

When I make a change to the core, I only test with the currently supported version of the Arduino IDE (currently 1.8.2) and that’s what most of the rest of the community are using as their IDE.

At the moment you have too many unkowns.
I’d recommend either you use the Arduino IDE or you contact the company who make the Visual Studio plugin etc and ask them to help.

Those warnings do not influence the functionality of the SPI.
What exactly mean “crash”?
dmd wrote:_currentSetting->bitOrder = bitOrder; //<<<<<<<<<<<<<<<<<<<<< CRASH HERE!!!!!!!!

dmd wrote:
Can you give me some examples (or better explain) about it?

RogerClark wrote:Sounds like the SPI class is may being correctly initialised under Visual Studio

Although there are a few people who use the LibMaple core with Visual Studio, the Core (LibMaple) is only designed to work with the Arduino IDE and then only specific versions of the IDE.

When I make a change to the core, I only test with the currently supported version of the Arduino IDE (currently 1.8.2) and that’s what most of the rest of the community are using as their IDE.

At the moment you have too many unkowns.
I’d recommend either you use the Arduino IDE or you contact the company who make the Visual Studio plugin etc and ask them to help.

stevestrong wrote:Those warnings do not influence the functionality of the SPI.
What exactly mean “crash”?
dmd wrote:_currentSetting->bitOrder = bitOrder; //<<<<<<<<<<<<<<<<<<<<< CRASH HERE!!!!!!!!

zoomx wrote:dmd wrote:
Can you give me some examples (or better explain) about it?

No. AMap is for opening MAP files (search the forum how to generate MAP files).

I give up, because it really seems that your problem is linked with the used plugin (VMicro) for visual studio, and I cannot help you there.

stevestrong wrote:No. AMap is for opening MAP files (search the forum how to generate MAP files).

I give up, because it really seems that your problem is linked with the used plugin (VMicro) for visual studio, and I cannot help you there.

Under Arduino ide i could test and debug your code, if you share it.

stevestrong wrote:Under Arduino ide i could test and debug your code, if you share it.

As I said, the old library worked.
According to the date of the code that I created, most likely it is the version 1.1.8 available here.

Https://github.com/miguelbalboa/rfid/re … fter=1.1.9

Maybe others work, too.
I need to test.

I looked for the reason that one would work and the other not, but I could not find.

Please share all your code (including the not working library), otherwise I cannot help you.
The simpliest way would be to attach a ZIP file to your post including the complete package.

It seems that you take the wrong pin on STM32 and sometimes there is a noise on mega as I can see on the middle image.

But it is very difficult to see from here

there is a saying that god help those who help themselves it is rather apt actually, there’s few substitute being the first person closest to the problem. the reason is someone else using a different environment compiling the same code, it may just well works for him/her, but by virtue of luck/fate etc possibly u’ve have particular combination that doesn’t work.

the rest of us can only give tips/clues of what we think based on our own limited experience what may alleviate your situation, but after all we may not have the answers too

stevestrong wrote:Please share all your code (including the not working library), otherwise I cannot help you.
The simpliest way would be to attach a ZIP file to your post including the complete package.

zoomx wrote:It seems that you take the wrong pin on STM32 and sometimes there is a noise on mega as I can see on the middle image.

But it is very difficult to see from here

ag123 wrote:there is a saying that god help those who help themselves it is rather apt actually, there’s few substitute being the first person closest to the problem. the reason is someone else using a different environment compiling the same code, it may just well works for him/her, but by virtue of luck/fate etc possibly u’ve have particular combination that doesn’t work.

the rest of us can only give tips/clues of what we think based on our own limited experience what may alleviate your situation, but after all we may not have the answers too

an additional hint, it is fairly likely _currentSetting is pointing to somewhere in flash.
if there is no debug, do a Serial.println(_currentSetting);

https://www.arduino.cc/en/serial/print
Serial.print(78, BIN) gives "1001110"
Serial.print(78, OCT) gives "116"
Serial.print(78, DEC) gives "78"
Serial.print(78, HEX) gives "4E"
Serial.println(1.23456, 0) gives "1"
Serial.println(1.23456, 2) gives "1.23"
Serial.println(1.23456, 4) gives "1.2346"

You can pass flash-memory based strings to Serial.print() by wrapping them with F(). For example :

Serial.print(F(“Hello World”))