Interesting Error on STM32F030K6 with remapped serial

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Thu Jan 17, 2019 2:35 am

Greetings,

I've ran into an interesting error on the STM32F030K6. I'm using both SPI1 and USART1. I've remapped the USART1 TX and RX DMA using the supplied method in mcuconf.h.

For whatever reason, if compiled with anything other than -O0, I can't run the SERIAL system at any speed beyond 19200. Doing so generates an unhandled exception. On the other hand, compiling with -O2 and 19200, I've generated over 18000 serial messages with ZERO problems.
Since the serial messages are strictly for development purposes, this is not a show stopper.

I've never ran into this problem with any other chip. This includes the STM32F030CC running the same application at 115200 and -O2.
I've also ran the same application on a STM32F103, STM32F303 and STM32F373 all at 115200 and -O2. I also have some STM32F030F4 that I might whip up a test board to see if they display the same problem, but that would take a couple of days.

I'm not calling this a bug because the STM32F030CC works just fine.
I could not find an Errata that was on point with the displayed problem.

Any ideas???

GB

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Interesting Error on STM32F030K6 with remapped serial

Postby Giovanni » Thu Jan 17, 2019 6:27 am

Hi,

I would check the exceptions stack size, then the other stacks, compiling without optimizations increases stack usage considerably.

Giovanni

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Thu Jan 17, 2019 9:42 am

Hi,

Ok, I must be a little dense or maybe it's just past my bed time... :shock:

Compiling at -O0, I can use whatever speed I want to, including 115200.
If I use -O2, anything over 19200 will bomb, 115200 dies within a minute. Using -O1 and 38400, it may go as long as an hour, but it will bomb.

The highest speed I can use with -O1 or -O2 is 19200, however that combo is rock solid, before I loaded a new firmware I had over 100,000 chprintf's using -O2 and 19200.

Please note, I have during my debugging/search for answers enabled all of the ChibiOS debugging vars outside of the Trace, that option required too much memory. I attached gdb via a BMP and waited... Every lockup was a unhandled exception and none of the asserts or other checks triggered.

I'm using the MCU to interface to a nrf24L01+ via SPI1 and printing information using SD1. Like I said before, this same application ran at 115200/-O2 on STM32F103, STM32F303, STM32F373 and STM32F030CC with no problem. The only thing I can think of is that has to with the DMA remapping of the USART TX and RX. All the lockups occur in the middle of a print.

I think I'll take the time tomorrow to whip up that STM32F030F4 board and see if it shows the same symptoms. That however will be just to settle my curiosity because 19200 is plenty fast enough for me.

GB
.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Interesting Error on STM32F030K6 with remapped serial

Postby Giovanni » Thu Jan 17, 2019 9:55 am

Hi,

I understood the opposite...

Anyway, it could be compiler related, which version are you using? GCC 6 and following are broken on Cortex-M0 and that causes RT and NIL to fail, if you are using GCC then make sure to use a 5.X.

Giovanni

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Thu Jan 17, 2019 11:50 am

Hi,

I'm using 'gcc version 7.3.1 20180622'. Until this little problem cropped up, never had a problem with it. Like I said the code runs just fine on the STM32F030CC which is of course a M0 core. I've got L0's on order coming next week.

Like I said, the only thing I can think of is that it's related to that DMA remap some how.

I'm going to do some more experiments and see what makes a difference besides the -O level and serial speed.

GB

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Interesting Error on STM32F030K6 with remapped serial

Postby Giovanni » Thu Jan 17, 2019 11:59 am

Hi,

Just remember that if you are using RT or NIL on M0 you are affected by the compiler bug, the result is not apparent (missing reschedules, higher latency) but it is real.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167

Giovanni

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Tue Jan 22, 2019 5:10 pm

Greetings,

I have found part of the problem.

If your using the SERIAL driver and not the USART driver, the dma channels are NOT remapped! :shock:

I included the following code right after the SERIAL driver is enabled. This is on a STM32F030F4 which is officially not supported(One file missing, copied from C6).

Code: Select all

chprintfSleep is set to 35

  uint32_t mycfgr1 = SYSCFG->CFGR1;
  if(mycfgr1 & SYSCFG_CFGR1_USART1TX_DMA_RMP) {
      chprintf((BSS *)&SD1, "TX DMA remapped\r\n");
        chThdSleepMilliseconds(chprintfSleep);
  }
  else {
      chprintf((BSS *)&SD1, "TX DMA NOT remapped\r\n");
        chThdSleepMilliseconds(chprintfSleep);
        uint32_t newtxcfgr1  = mycfgr1;
        newtxcfgr1 |= SYSCFG_CFGR1_USART1TX_DMA_RMP;
        SYSCFG->CFGR1 = newtxcfgr1;
        uint32_t txcfgr1 = SYSCFG->CFGR1;
            if(txcfgr1 & SYSCFG_CFGR1_USART1TX_DMA_RMP) {
                chprintf((BSS *)&SD1, "TX DMA remapped\r\n");
                    chThdSleepMilliseconds(chprintfSleep);
            }
  }


The RX side is identical except for changing TX to RX.

The first three lock cycles are ran atleast 5 times to get the numbers.
Ok, -O2 and 115200 locks at 1034
-O1 and 38400(2sec pause on cycle) locks at 768
-O1 and 38400(No pause) locks at 763
-Og and 38400 no locks

Don't have a clue...

GB

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Interesting Error on STM32F030K6 with remapped serial

Postby Giovanni » Tue Jan 22, 2019 7:15 pm

Hi,

Not sure what I am looking at but two notes:

- The serial driver does not use DMA, UART driver does.
- Drivers do not set the remap bits in SYSCFG->CFGR1 by themselves, you need to remap DMAs before starting the driver.

Giovanni

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Wed Jan 23, 2019 1:57 am

Greetings,

Ok, then the DMA has nothing to do with the problem then.

I've upgraded to arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213
and -O2 is still locking on the cycle 1034 EVERY time. From looking at that bug, I don't think this is it. This code works just fine on a STM32F030CC which is of course a Cortex-M0 also. I've had one of those running now for over 4 days and if it was a memory leak that triggered exactly 1034 cycles, then the CC's 8x memory should have been exhausted. Right now that CC is over 10 million cycles. I'm thinking this is hardware bug that I'm tickling;
The core hardware is different between the F/K and C/R, not only in memory/flash but also the periphs.

(I've had this reply open now for about an hour... :D )
Another data point, if I compile with -fno-omit-frame-pointer then the program (The same one I've been running) that only ran to 378 cycles on a STM32F030K6 has ran for over 6000 make that 35000+ cycles at 115200 with -O2.

Hopefully that will tell someone where to look....

GB
EDIT to change number of cycles.

gclarkii
Posts: 24
Joined: Wed Mar 01, 2017 7:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Interesting Error on STM32F030K6 with remapped serial

Postby gclarkii » Fri Jan 25, 2019 10:11 am

Greetings,

Ok, that STM32F030K6 has been running since I posted that message. It has looped at least once on a uint32_t counter so I'm going to call the no-omit-frame-pointer as valid work around for whatever caused it. It bumped the binary size a little(about 400 bytes) and I don't see a slow down with the naked eye. The project has an overkill on horsepower as I'm running it on STM32F030(of various types) whereas a STM8 could have run it but I don't like the architecture. All it does is echo a ping that comes in via a nrf24L01+ board, even with full C++ support it only comes out to about 14K which is why I was playing with the F4.

It is obvious that whatever the problem was, it was trashing the native stack/frame as using the no-omit-frame-pointer directive cured it as far as I can tell.

Again the original problem was on the STM32F030K6/F4 the system would lock with a unhandled exception using SPI and SERIAL at 115200 if compiled with -O1 or -O2(at the SAME exact loop counter position each time). A STM32F030CC running the same code would NOT lock. Compiling with -Og or running at 19200 would not generate the lock. Compiling with no-omit-frame-pointer would make it work with both -O2 and 115200. BTW, just for grins I recompiled for 230400 and it's looped a uint32_t counter once already(Meaning when it hits MAX -1 I reset the counter to 1 and increment a loop counter). Maybe someone who knows the internals better than I do can figure out if the problem is hardware, the compiler or me. :mrgreen:


GB


Return to “STM32 Support”

Who is online

Users browsing this forum: Bing [Bot] and 16 guests