Ok, finally found the problem. Couldn't let this stand. Just submitted PR to fix this: https://github.com/apache/incubator-nuttx/pull/1310
It was indeed a VERY time sensitive bug. Best, Matias On Mon, Jun 22, 2020, at 10:25, Matias N. wrote: > In my case I have STM32L476, so this is not the problem. Errata document did > not help either, couldn't find anything that matches my problem. > > On Mon, Jun 22, 2020, at 10:21, David Sidrane wrote: >> Hi Matias, >> >> >> > > Yes, I do recall some issue with the F429's in this regard. There was >> >> > > an errata. I believe that there are some pins in the upper 256Kb bank >> >> > > that interfered with some other peripheral. DavidS would know better >> >> > > than I. I thought it effected USB? >> >> The FLASH/USB related silicon errata in the F42{7|9} was fixed on newer >> silicon. The simple fix was when using USB do not use the second Meg of >> flash. See >> https://docs.px4.io/v1.9.0/en/flight_controller/silicon_errata.html >> >> There is code >> https://github.com/PX4/Firmware/blob/master/platforms/nuttx/src/px4/stm/stm32_common/version/board_mcu_version.c >> to ID the chip and version. >> >> David >> >> >> -----Original Message----- >> From: Matous Pokorny [mailto:matous.pokorny@datavision.software] >> Sent: Monday, June 22, 2020 6:12 AM >> To: dev@nuttx.apache.org >> Subject: Re: MCU only booting from reset via SWD when compiled without >> optimizations? >> >> Hello, >> >> I do not have the answer to your question. I have some notes which could >> help you. >> >> 1) Check the boot issues related to dual bank flash as mentioned. You have >> the part number with dual bank. Check the option bytes as well. >> 2) I met the problem that SW reset does not work if you have SWDIO with >> reset pin attached (SWDIO probe keeps the pin in one level and SW reset >> pull the pin to another level, I have to put galvanic isolation between). >> Crazy is that SW reset has HW consequences (GPIO). >> 3) Check the link and boot address related to dual bank. >> 4) You did not note the compiler etc. Check the linker script is the same >> for both versions - with and without optimization. >> 5) Compare the result after disassembling the binary and focus on >> differences during the boot sequence. The boot sequence contains simple >> code. Optimization has a small impact on it. >> >> Good luck, Mat. >> _____________________________ >> *Matouš Pokorný* | Embedded system developer >> matous.pokorny@datavision.software >> >> >> >> po 22. 6. 2020 v 0:56 odesílatel Matias N. <mat...@imap.cc> napsal: >> >> > Ah, it is STM32L476RET. So, that wouldn't be the problem, but I have to >> > check the errata for this chip. >> > It is 62 pages long =| >> > >> > On Sun, Jun 21, 2020, at 19:50, Gregory Nutt wrote: >> > > On 6/21/2020 4:36 PM, Gregory Nutt wrote: >> > > > >> > > >> I will consider this possibilities, thanks. >> > > >> >> > > >> What is driving me crazy is that it actually seems to be triggered by >> > > >> the binary being bigger than 256KB (MCU has 512KB, dual bank). I >> > > >> already had to use openocd from git since it would not flash the >> > > >> image in that case. Now openocd flashes correctly. However, the bad >> > > >> reset behavior also seems to happen in this case. I have the same >> > > >> problem with optimization turned on but which increases binary size >> > > >> above 256KB. >> > > >> >> > > >> I cannot think something in the code that would change in this case, >> > > >> since banks are contiguous. Maybe some chip errata, I don't know. >> > > > >> > > > Yes, I do recall some issue with the F429's in this regard. There was >> > > > an errata. I believe that there are some pins in the upper 256Kb bank >> > > > that interfered with some other peripheral. DavidS would know better >> > > > than I. I thought it effected USB? >> > > > >> > > > You never mention which part you are using (or perhaps wan't paying >> > > > attention). You should check the errata. >> > > >> > > I think this is the errata I was thinking of. In the STM32F42xx and >> > > STM32F43xx Errata sheet: >> > > >> > > 2.2.10 PA12 GPIO limitations >> > > >> > > Description >> > > When PA12 is used as GPIO or alternate function in input or output >> > > mode, the data read >> > > from Flash memory can be corrupted. This behavior is observed only >> > > when the following >> > > conditions are met: >> > > >> > > • The device operates from a 2.7 to 3.6 V VDD power supply whatever >> > > the temperature >> > > range >> > > • Flash memory Bank2 is used or the dual bank feature is enabled. >> > > >> > > Impacted products >> > > • STM32F42xxI and STM32F43xxI part numbers >> > > • STM32F42xxG and STM32F43xxG part numbers only when dual bank >> > > feature is >> > > enabled. >> > > >> > > Not impacted products >> > > • STM32F42xxG and STM32F43xxG part numbers when dual bank feature is >> > > disabled >> > > • STM32F42xxE and STM32F43xxE part numbers. >> > > >> > > Workaround >> > > PA12 must be left unconnected on the PCB (configured as push-pull >> > > and held Low). You >> > > can use all the other GPIOs and all alternate functions except for >> > > the ones mapped on >> > > PA12. Use the OTG_HS peripheral in full-speed mode instead of the >> > > OTG_FS peripheral. >> > > >> > > This limitation is fixed in silicon starting from revision 3. >> > > >> > > Note that this has been fixed in current versions. >> > > >> > > >> > >> >