fpiSTM , if you care to look at the code, this is an issue in a file in Arduino_Core_STM32. https://github.com/stm32duino/Arduino_Core_STM32/blob/master/tools/platformio/platformio-build.py
is in your repository, so maintained by you I assume, and that sets a build flag for all cortex-m4 MCU's ...
Search found 20 matches
- Sun Aug 15, 2021 1:41 pm
- Forum: General discussion
- Topic: STM32WL support
- Replies: 18
- Views: 16446
- Sun Aug 15, 2021 8:45 am
- Forum: General discussion
- Topic: STM32WL support
- Replies: 18
- Views: 16446
Re: STM32WL support
OK, with the following change https://github.com/stm32duino/Arduino_C ... o?expand=1
I did manage to turn off the fpu stuff on from tools/platformio/platformio-build.py. Should I submit that as PR?
I did manage to turn off the fpu stuff on from tools/platformio/platformio-build.py. Should I submit that as PR?
- Sun Aug 15, 2021 7:14 am
- Forum: General discussion
- Topic: STM32WL support
- Replies: 18
- Views: 16446
Re: STM32WL support
Awesome fpiSTM . Thanks so much. Haven't really had time to do anything with the stm32duino and my stm32wl55 board until today. Right now I am looking at getting it included in Platformio . I know you're not the one making the Platformio packages/framework definition, but I am running into an issue ...
- Tue Jan 26, 2021 2:30 pm
- Forum: General discussion
- Topic: STM32WL support
- Replies: 18
- Views: 16446
STM32WL support
Hey all, what are the chances of getting STM32WL support in the STM32Core?
- Mon Jan 04, 2021 5:54 am
- Forum: General discussion
- Topic: Compensate for LSE error
- Replies: 12
- Views: 12249
Re: Compensate for LSE error
unless you are using something truly bad, those crystals are spec'd to 20ppm and usually within 5ppm. so 5% is a little extraordinary.
I would first verify the cause. if it is indeed in the crystal, the hardware does allow LSE compensation - look to the reference manual. but unlikely to the ...
- Tue Dec 22, 2020 3:16 am
- Forum: General discussion
- Topic: Compensate for LSE error
- Replies: 12
- Views: 12249
Compensate for LSE error
Hey all, I am using a custom board with an STM32F103C8 with an LSE and HSE clock using the STM32 core and the stm32duino RTC and LowPower libraries. I am putting my MCU to sleep using stop mode (deepsleep in stm32duino Low Power lingo) and wake up from an RTC alarm. Although the sensor says it will ...
- Tue Jun 23, 2020 1:54 am
- Forum: General discussion
- Topic: Detecting what interrupt was triggered
- Replies: 4
- Views: 4106
Re: Detecting what interrupt was triggered
Cool, thanks again for your help fpiSTM . I didn't know that doc existed. It helps a lot. But it turns out the IRQ was triggered by my STLink debugger. I am using it to upload the code. Even without actually debugging, it looks like after flashing the code, the STLink debugger triggers an interrupt ...
- Mon Jun 22, 2020 7:44 am
- Forum: General discussion
- Topic: Detecting what interrupt was triggered
- Replies: 4
- Views: 4106
Re: Detecting what interrupt was triggered
Ok, but can you elaborate a little on which registers I need to check? I am browsing through the STM32 reference manual and code, but there is so much of it that it's hard to figure out which ones I need to check, and how I can disable interrupts. Are there functions or specific registers that tell ...
- Mon Jun 22, 2020 6:05 am
- Forum: General discussion
- Topic: Detecting what interrupt was triggered
- Replies: 4
- Views: 4106
Detecting what interrupt was triggered
Using the STM32 Arduino Core on an STM32F103C8, I am having an issue, probably with a 3rd party library, where some interrupt gets triggered, causing LowPower.deepSleep to wakeup straight away, instead of sleeping until the RTC alarm occurs. Is there a way to see what interrupts get triggered, and ...
- Mon Jun 22, 2020 4:51 am
- Forum: General discussion
- Topic: LowPower.deepSleep conflict with RX1 serial port
- Replies: 4
- Views: 5844
Re: LowPower.deepSleep conflict with RX1 serial port
To make the problem above clearer: In the small example that I gave, indeed issuing the Serial.flush() did solve the issue there, but in my real life code (too big to post here), I am making use of 3rd party libraries. There I have added Serial.flush() statements everywhere I debug print stuff, and ...