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.
>> > >
>> > >
>> >
>>
>
