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