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

Reply via email to