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. On Sun, Jun 21, 2020, at 18:51, Gregory Nutt wrote: > > > The appropriate thing to do would be to check reset signal using an > > oscilloscope but i don't have one here. > > > > Anyway, I simply wanted to ask if by any chance this could be due to some > > oversight related to how the non-optimized build could affect this, based > > on someone else experience with the same problem. But I guess it is pretty > > specific. > > We can assume that the unoptimized code is correct (it usually is, the > optimized code sometimes is not). Then the only effects of unoptimized > code that I can think of might be: > > 1. Parts of the boot-up code assume that .data and .bss will not be > used. These are initialized later after several startup functions have > been called. What if unoptimized code were to require some global data > initialization? This is possible but not likely. > > 2. Timing will be different. Delay loops will be much longer. If there > is any critical code that assumes a quick action, that action will be > delayed. > >
