fix STM32F1 ADC read temperature error after connect USB CDC

[bigtreetech]

Requirements

• Filling out this template is required. Pull Requests without a clear description may be closed at the maintainers' discretion.

Description

1. fix this issue [FIXED] SKR Mini E3 & E3 DIP - Temp Error if USB connected on boot #14818
2. if you connect usb cdc serial, It tampers with data in RAM. it will cause here

   Marlin/Marlin/src/HAL/HAL_STM32F1/HAL.cpp

   Line 96 in e604f76

   uint8_t adc_pins[] = {

   
   incorrect pins in the array adc_pins[]
3. now the adc_pins[] array stored in flash, this ensures that it will not be tampered.
4. I don't know why connected to USB CDC can tamper with data in RAM. This method can only ensure that ADC works normally. and maybe this issue(tamper data in RAM) will cause some other problems.

Benefits

Related Issues

#14818

[EDIT]
The bug has been found. in here rogerclarkmelbourne/Arduino_STM32#661.

when adc_pins[] defined in ram, adc_pins[0] will be tampered form TEMP_0_PIN to 0xC8, if it defined in flash, Running will be tampered form 1 to 0xC8, Because of Running is a bool variable, so 0xC8 works the same as 1.

[tpruvot]

Indeed, that fixes the issue i had on the skrmini. Really weird bug.

[gloomyandy]

So rather than overwriting the adc configuration the CDC code will now overwrite something else? That does not sound like a good idea (and frankly sounds like a fire or something waiting to happen). If the CDC code is corrupting memory then that is a pretty serious bug and needs to be fixed, if not you are just going to see more and more "random" bug reports related to CDC use. I'd argue that the only "safe" fix for this (until the real problem is identified) is to disable the use of CDC.

[tpruvot]

maybe the cdc feature requires some memory range reservation...

[tpruvot]

i see something here https://github.com/rogerclarkmelbourne/STM32duino-bootloader/ in the readme about user memory area

[looxonline]

I've worked with products that were installed into some pretty harsh electronic environments (motor vehicles with alternator noise) and seen RAM corruption many times. It was almost always caused by one or both of two factors:

1.) Unstable clock source.
2.) Voltage dips below the recommended operating range but above the brown out detect threshold.

If we are powering this off USB is there enough voltage to keep the rails from dipping? It would seem that with the repeatability of the issue it could be some other part of software overwriting this area in RAM which would then be another fix altogether.

[thinkyhead]

Is const guaranteed to always be stored in flash on this platform? Just want to make sure compiler quirks or optimization flags don't bite us later.

[tpruvot]

Is const guaranteed to always be stored in flash on this platform? Just want to make sure compiler quirks or optimization flags don't bite us later.

no, there is __FLASH__ for that (which do the reverse of PROGMEM attribute)
tested today on our logo... (part of .rodata)

STM32F1/cores/maple/wirish_types.h:63:#define __FLASH__ __attr_flash
STM32F1/system/libmaple/include/libmaple/libmaple_types.h:56:#define __attr_flash __attribute__((section (".USER_FLASH")))

[reloxx13]

link noted by @tpruvot
[bugfix] Restore overflowed memory copy (PR from BTT) rogerclarkmelbourne/Arduino_STM32#661