Hi Tim, Yes, get a solid settings before moving forward is the best approach.
Thank you very much, have a great Xmas and a Happy New Year! BR, Alan On 12/22/21, TimH <t...@jti.uk.com.invalid> wrote: > This is a custom board (SAMA5D27-D5M). I suspect what has happened is > that multiple "messing around" with configs has broken something basic. > > To add insult to injury I have messed it all up so badly that the apps > directory won't compile in properly either now. > > I will take your advice and return to basics. I'll start with a clean > config based on a similar board and ignore all my new stuff to get the > basics working. I will also make the move to latest NuttX and get to > grips with GitHub upstream repos so I can better keep up with latest. > > So, now I break for Christmas and New Year, and will start again in > January with a clear head...maybe! > > I REALLY appreciate your help, Alan...have a good Christmas/New > Year...and, sorry, but I'll be back LOL. > > On 22/12/2021 17:49, Alan Carvalho de Assis wrote: >> Exactly, something is changing the memory layout and forcing the error >> to happen. >> >> I can try duplicate it later, but I think it could be specific for >> your board configuration. What board/MCU are you using? >> >> BR, >> >> Alan >> >> On 12/22/21, Tim<t...@jti.uk.com.invalid> wrote: >>> Usb_msc_main.c >>> >>> If I add a "return OK" as the first line of main, msconn runs and >>> returns. >>> >>> If I put a printf statement before it, I get a crash. >>> >>> If I do the same in an example app I've written, it is fine. >>> >>> If I put a breakpoint at the printf statement and step over it, into >>> there >>> it gets to "void exit(int status)", then nxtask_exithook(tcb, status, >>> false), then group_leave(tcb). >>> >>> This is crazy...I just don't get this - surely a built in system app >>> should >>> not be crashing like this!!! >>> >>> >>> >>> >
