Arduino for STM32

Hello, A year ago I made a controller with Arduino Mega but recently I learned there was no good trusting in arduino so I bought STM32F411C(512kb Blackpill) and STM32F401CC(256kb Blackpill). I have been coding and implementing for STM32F411(512kb) using Arduino IDE(I compile the code and upload as .bin file thru stm32cube programmer.) so code (198 kb) worked as expected I tested it and there was no problem then I decided to try it with STM32F401CC(256kb) but serial communication did not work. I am using max6675 thermocouple sensor, Nextion Tft Screen and External eeprom.
I need to use serial communication in order to use nextion tft screen.

I tested every single sensor individually, they all worked as expected. Then I tried my code bit by bit ( first void setup then functions) and I realized if sketch uses more then %50 of flash memory serial communication wont be working.

Hi,
I don't think it is linked to flash size but to other reason.
But hard to tell which one without the code. Some input: RAM usage? IRQ? interrupt handler management?

fpiSTM wrote: Tue Nov 15, 2022 1:07 pm Hi,
I don't think it is linked to flash size but to other reason.
But hard to tell which one without the code. Some input: RAM usage? IRQ? interrupt handler management?

Hi fpiSTM,
Thanks for replying. My RAM usage is %40 (26512), as for the IRQ I never disabled or enabled it in my code.
I am not sure will it effect but stm32 reset itself after opening for first time. I did that because stm was slow at writing values that are read from eeprom to nextion and reseting fixed my issue. This is what I mean:
if(EEPROM.read(3565))
{
EEPROM.write(3565,0);
NVIC_SystemReset();
}

Ksrdropper wrote: Tue Nov 15, 2022 2:27 pm

fpiSTM wrote: Tue Nov 15, 2022 1:07 pm Hi,
I don't think it is linked to flash size but to other reason.
But hard to tell which one without the code. Some input: RAM usage? IRQ? interrupt handler management?

Hi fpiSTM,
Thanks for replying. My RAM usage is %40 (26512), as for the IRQ I never disabled or enabled it in my code.
I am not sure will it effect but stm32 reset itself after opening for first time. I did that because stm was slow at writing values that are read from eeprom to nextion and reseting fixed my issue. This is what I mean:
if(EEPROM.read(3565))
{
EEPROM.write(3565,0);
NVIC_SystemReset();
}

So I tried without NVIC_SystemReset(); my stm and it worked also slowness seems to be normal. Everything works as expected.
Thank you! Thanks for asking about IRQ.

Hum, you told you used external EEPROM ? but your code is for EEPROM emulation.
This explain your issue as for STM32F401CC:

Sector 7 0x0806 0000 - 0x0807 FFFF 128 Kbytes

So with EEPROM emulation the last sector is used but your program goes into this sector.
Simply try to remove the EEPROM write and I guess your program will run fine.

Slowness is due to EEPROM operation.

fpiSTM wrote: Tue Nov 15, 2022 3:26 pm Hum, you told you used external EEPROM ? but your code is for EEPROM emulation.
This explain your issue as for STM32F401CC:

Sector 7 0x0806 0000 - 0x0807 FFFF 128 Kbytes

So with EEPROM emulation the last sector is used but your program goes into this sector.
Simply try to remove the EEPROM write and I guess your program will run fine.

Slowness is due to EEPROM operation.

I was using them both so now I am just working with just external eeprom also I tested under wrong circumstances (my usb cable was connected to my pc which is also fixes my issue but controller is used without being connected to a pc) the slowness of sending data to nextion is still there, I tried adding NVIC_SystemReset(); again but stm32 did not work, so my first problem was with NVIC_SystemReset(). So now when I omit reset serial communication slows down when I include reset my stm32 stops working.

Well the nvic reset probably add issue if you used I2C device as bus could probably be stuck or something like that.
I advice to not used the reset or ensure to properly init all hardware after this reboot.

Anyway, I gues the issue with Serial with program higer than 50% is solved (and explained) due to the use of virtual EEPROM?