You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Robert Middleton <os...@gmail.com> on 2021/02/21 15:40:55 UTC
Issues with PIC32
Hi all,
I wanted to test out NuttX and I've run into some very weird issues
with compiling and running on a PIC32. I don't have any boards that
are exactly the same as one of the sample configurations, but my
assumption is that this is not an issue. I currently have two boards
that I'm testing with: a chipKIT Max32, and an older Explorer 16 from
Microchip. My starting point is with the pic32mx-starterkit
configuration in the boards/mips/pic32mx directory.
I've only gotten output on the serial port about two times; all the
other times it seems as though it panics very early in the boot
process. One time it seemed to show some kind of memory dump, the
other time I got a bus fetch exception at address 0x0. Moreover, it
seems very inconsistent as to when it will actually output anything on
the serial port - I can recompile what I think is the same
version(same configuration settings), but running it will result in no
output.
I've tried using a compiler I built using crosstool-ng, but ld doesn't
recognize -nostartfiles for some reason. I've also tried using
Debian's MIPS cross-compiler. The final compiler I tried is a also
built with crosstool-ng, from this repo[1]. All show the same issue.
* Are my assumptions that I should just be able to build and run NuttX
on the explorer16/max32 incorrect? I only care about getting a
console on serial at the moment so I can start messing around with
things.
* What can I do to debug early boot problems?
* Is there a better compiler to use?
-Robert Middleton
[1]: https://github.com/MajenkoProjects/crosstool-ng-pic32
Re: Issues with PIC32
Posted by Barbiani <ba...@gmail.com>.
I was able to run nuttx on this board
<https://www.mikroe.com/mikromedia-4-pic32mx7> .
Had to change some fuses to get it working with pinguino. Ethernet was up,
but crashed after receiving a few pings.
On Sun, Feb 21, 2021 at 10:08 PM Robert Middleton <os...@gmail.com>
wrote:
> > I don't have an actual Microchip Explorer16/32 which it sounds like
> > you are working on, but if you were to put a draft PR up or point me
> > at a branch I would be happy to try to run this against the simulator
> > and see if we can get a little further.
> >
> > This is the simulator I was using https://github.com/sergev/qemu/wiki
> > I did have to make a few changes to get it to build with a modern
> > gcc/glibc
> >
>
> This may be a typo on your side, but I'm testing with an MX, not an
> MZ. I did just try it with that simulator, and I get an error about
> writing to peripheral register 1f800600 being not supported.
>
> Here's the branch that I'm working off of at the moment. It also has
> a fix for defining CONFIG_SERIAL_TERMIOS with the PIC32, which doesn't
> properly compile:
> https://github.com/rm5248/incubator-nuttx/tree/pic-messing-around
>
> You should be able to get the proper configuration by doing
> ./tools/configure.sh -E -l pic32mx-explorer16:nsh. Note that the
> explorer16 has the output on UART2 - I don't remember if you can
> switch which UART qemu is using to see that output. Switching it to
> UART1 for the simulator should be fine though.
>
> -Robert Middleton
>
Re: Issues with PIC32
Posted by Robert Middleton <os...@gmail.com>.
The patch for the context switching works perfectly, thanks! I do now
have it working on the actual hardware as well, so I can start messing
around with some stuff.
-Robert Middleton
Re: Issues with PIC32
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sun, Feb 21, 2021 at 5:08 PM Robert Middleton <os...@gmail.com> wrote:
>
> > I don't have an actual Microchip Explorer16/32 which it sounds like
> > you are working on, but if you were to put a draft PR up or point me
> > at a branch I would be happy to try to run this against the simulator
> > and see if we can get a little further.
> >
> > This is the simulator I was using https://github.com/sergev/qemu/wiki
> > I did have to make a few changes to get it to build with a modern
> > gcc/glibc
> >
>
> This may be a typo on your side, but I'm testing with an MX, not an
> MZ. I did just try it with that simulator, and I get an error about
> writing to peripheral register 1f800600 being not supported.
That is TIMER1 I just wrote a patch for that. I'll try and get that
in a little better place.
>
> Here's the branch that I'm working off of at the moment. It also has
> a fix for defining CONFIG_SERIAL_TERMIOS with the PIC32, which doesn't
> properly compile:
> https://github.com/rm5248/incubator-nuttx/tree/pic-messing-around
>
> You should be able to get the proper configuration by doing
> ./tools/configure.sh -E -l pic32mx-explorer16:nsh. Note that the
> explorer16 has the output on UART2 - I don't remember if you can
> switch which UART qemu is using to see that output. Switching it to
> UART1 for the simulator should be fine though.
Ok running this in the sim I was getting the init thread failing to be
crated, so I enabled debug asserts and get this:
❯ ./mipsel-softmmu/qemu-system-mipsel -machine pic32mx7-explorer16
-nographic -monitor none -serial stdio -kernel
~/nuttx/wrk/nuttx/nuttx.hex -S -s
Board: Microchip Explorer16
Processor: M4K
RAM size: 128 kbytes
Load file: '/home/bashton/nuttx/wrk/nuttx/nuttx.hex', 250820 bytes
nx_start: Entry
up_assert: Assertion failed at file:mm_heap/mm_initialize.c line: 82
up_dumpstate: sp: a0001b14
up_dumpstate: stack base: a0001c0c
up_dumpstate: stack size: 00001000
up_stackdump: a0001b00: 9d03ad90 a0001b24 9d03a9bc a0001b00 a0001b00
a0001b1c 9d00cecc a0001b14
up_stackdump: a0001b20: a0001c0c 9d03adf0 00001000 a00003fc a0001b14
a0001c0c 00001000 a0001b44
up_stackdump: a0001b40: 9d00b990 00000000 9d03a9bc 9d03a9e8 9d03a104
00000052 00000000 a0001b64
up_stackdump: a0001b60: 9d006260 9d03a104 00000052 a0008061 9d0326cc
a0001b7c 9d008d1c 9d03a104
up_stackdump: a0001b80: 00000052 bf8860c0 a0001b8c a00009a4 00000000
00000001 9d008700 a0001ba4
up_stackdump: a0001ba0: 9d008f78 a00009a4 a0001c0c 0001e3f4 bf8860c0
0000000c a0001bbc a0001bc4
up_stackdump: a0001bc0: 9d008bb4 a00009a4 a0001c0c 0001e3f4 00000003
a0001bdc 9d000380 a0001c0c
up_stackdump: a0001be0: 0001e3f4 ffffffff 00000008 00000010 00000000
00000000 a000038c a0001c0c
up_stackdump: a0001c00: 0001e3f4 00000000 9d000020 00000000 00000000
00000000 00000000 00000000
Dropping the breakpoint on _assert we can then see exactly what is
going on here:
Breakpoint 1, _assert (filename=0x9d03a104 "mm_heap/mm_initialize.c",
linenum=82) at assert/lib_assert.c:36
36 up_assert(filename, linenum);
(gdb) bt
#0 _assert (filename=0x9d03a104 "mm_heap/mm_initialize.c",
linenum=82) at assert/lib_assert.c:36
#1 0x9d008d1c in mm_addregion (heap=0xa00009a4 <g_mmheap>,
heapstart=0xa0001c0c, heapsize=123892) at mm_heap/mm_initialize.c:82
#2 0x9d008f78 in mm_initialize (heap=0xa00009a4 <g_mmheap>,
heapstart=0xa0001c0c, heapsize=123892) at mm_heap/mm_initialize.c:203
#3 0x9d008bb4 in umm_initialize (heap_start=0xa0001c0c,
heap_size=123892) at umm_heap/umm_initialize.c:85
#4 0x9d000380 in nx_start () at init/nx_start.c:552
#5 0x9d000020 in __start_nuttx () at chip/pic32mx_head.S:582
Backtrace stopped: frame did not save the PC
(gdb) up
#1 0x9d008d1c in mm_addregion (heap=0xa00009a4 <g_mmheap>,
heapstart=0xa0001c0c, heapsize=123892) at mm_heap/mm_initialize.c:82
82 DEBUGASSERT(heapsize <= MMSIZE_MAX + 1);
(gdb) p heapsize
$1 = 123892
(gdb)
Then looking at the definition of MMSIZE_MAX we see
"include/nuttx/mm/mm.h" 509L
#ifdef CONFIG_MM_SMALL
typedef uint16_t mmsize_t;
# define MMSIZE_MAX UINT16_MAX
#else
typedef uint32_t mmsize_t;
# define MMSIZE_MAX UINT32_MAX
#endif
Your configuration is using CONFIG_MM_SMALL so heap could not be
allocated correctly and we would likely get all kinds of unexpected
behavior.
Resolving that then takes us to another assert failure:
#5 0x9d00cea8 in up_irqinitialize () at chip/pic32mx_irq.c:116
116 up_prioritize_irq(PIC32MX_IRQSRC_CS0, (CHIP_SW0_PRIORITY << 2));
(gdb) down
#4 0x9d00d4ec in up_prioritize_irq (irq=129, priority=24) at
chip/pic32mx_irq.c:476
476 DEBUGASSERT((unsigned)irq < NR_IRQS && (unsigned)(priority >> 2) > 0);
This now starts to explain why the context switch is not happening and
up_swint0 is not triggered
up_prioritize_irq should be called with the real interrupt number not
the offset used when enabling and disabling interrupts:
===include/pic32mx/irq_5xx6xx7xx.h====
#define PIC32MX_IRQ_U5 51 /* Vector: 51, UART5 */
#define PIC32MX_IRQ_BAD 52 /* Not a real IRQ number */
#define NR_IRQS 52
/* Interrupt numbers. These should be used for enabling and disabling
* interrupt sources. Note that there are more interrupt sources than
* interrupt vectors and interrupt priorities. An offset of 128 is
* used so that there is no overlap with the IRQ numbers and to avoid
* errors due to misuse.
*/
#define PIC32MX_IRQSRC0_FIRST (128+0)
#define PIC32MX_IRQSRC_CT (128+0) /* Vector: 0, Core Timer Interrupt */
So this change should resolve that:
commit e4439d51d07fbc1357deb06dea6913ee0e3a92ab (HEAD -> pic-messing-around)
Author: Brennan Ashton <ba...@brennanashton.com>
Date: Sun Feb 21 19:54:58 2021 -0800
Fix context switch bug for pic32mx
diff --git a/arch/mips/src/pic32mx/pic32mx_irq.c
b/arch/mips/src/pic32mx/pic32mx_irq.c
index a8df13ee79..6ac35e3aa5 100644
--- a/arch/mips/src/pic32mx/pic32mx_irq.c
+++ b/arch/mips/src/pic32mx/pic32mx_irq.c
@@ -113,7 +113,7 @@ void up_irqinitialize(void)
/* Set the Software Interrupt0 to a special priority */
- up_prioritize_irq(PIC32MX_IRQSRC_CS0, (CHIP_SW0_PRIORITY << 2));
+ up_prioritize_irq(PIC32MX_IRQ_CS0, (CHIP_SW0_PRIORITY << 2));
/* Set the BEV bit in the STATUS register */
We now see the shell: (note I did disable most of the debug features
you had enabled like the ones for memory managment)
❯ ./mipsel-softmmu/qemu-system-mipsel -machine pic32mx7-explorer16
-nographic -monitor none -serial stdio -kernel
~/nuttx/wrk/nuttx/nuttx.hex
Board: Microchip Explorer16
Processor: M4K
RAM size: 128 kbytes
Load file: '/home/bashton/nuttx/wrk/nuttx/nuttx.hex', 250312 bytes
nx_start: Entry
uart_register: Registering /dev/console
uart_register: Registering /dev/ttyS0
uart_register: Registering /dev/ttyS1
nx_start_application: Starting init thread
NuttShell (NSH) NutnxtX_s-1tart0: .0.1
nsh> CPU0: Beginning Idle Loop
nsh> uname -a
NuttX 10.0.1 198649273f-dirty Feb 21 2021 18:53:48 mips pic32mx-starterkit
Hopefully this was helpful and gets you unblocked.
--Brennan
Re: Issues with PIC32
Posted by Robert Middleton <os...@gmail.com>.
> I don't have an actual Microchip Explorer16/32 which it sounds like
> you are working on, but if you were to put a draft PR up or point me
> at a branch I would be happy to try to run this against the simulator
> and see if we can get a little further.
>
> This is the simulator I was using https://github.com/sergev/qemu/wiki
> I did have to make a few changes to get it to build with a modern
> gcc/glibc
>
This may be a typo on your side, but I'm testing with an MX, not an
MZ. I did just try it with that simulator, and I get an error about
writing to peripheral register 1f800600 being not supported.
Here's the branch that I'm working off of at the moment. It also has
a fix for defining CONFIG_SERIAL_TERMIOS with the PIC32, which doesn't
properly compile:
https://github.com/rm5248/incubator-nuttx/tree/pic-messing-around
You should be able to get the proper configuration by doing
./tools/configure.sh -E -l pic32mx-explorer16:nsh. Note that the
explorer16 has the output on UART2 - I don't remember if you can
switch which UART qemu is using to see that output. Switching it to
UART1 for the simulator should be fine though.
-Robert Middleton
Re: Issues with PIC32
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sun, Feb 21, 2021 at 11:25 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > ... Using
> > the pinguino toolchain, 2 LEDs now light up, and the debugger at least
> > thinks that we're in the up_idle function, so that looks promising.
> > After switching the serial console to UART2(for the explorer16), I do
> > now get data out of the serial port! The last message that I see is
> > "nx_start: CPU0: Beginning Idle Loop". Nothing else is happening
> > though - I was expecting to get some kind of shell, as USER_ENTRYPOINT
> > is set to "nsh_main".
>
> That means that the OS bring-up completed without error but something
> failed while starting the application. Perhaps the memory is still
> configured wrong or perhaps the NSH stack size is too small. It is
> impossible to diagnose without debugging.
>
> I would put a breakpoint on nsh_main and see if it gets there.
>
Robert I did a quick verification via a qemu based simulator that I
was able to run nsh.
I did find a couple things. One was a invalid register write for port K
https://github.com/apache/incubator-nuttx/pull/2886
The other more concerning one was that when I did not build with the
debug features enabled I had what the simulator at least thought was
an invalid hex file with an entry starting on an odd address:
❯ ./mipsel-softmmu/qemu-system-mipsel \
-machine pic32mz-explorer16 \
-nographic -monitor none \
-serial stdio \
-kernel ~/nuttx/wrk/nuttx/nuttx.hex -S -s
Board: Microchip Explorer16
Processor: microAptivP
RAM size: 512 kbytes
/home/bashton/nuttx/wrk/nuttx/nuttx.hex: odd address
Note that I was abusing a different config "pic32mz-starterkit:nsh"
and I had to make a few tweaks including disabling
CONFIG_MIPS_MICROMIPS and I believe there also may be a limitation in
the simulator around SRSCtl that I also hacked around.
I don't have an actual Microchip Explorer16/32 which it sounds like
you are working on, but if you were to put a draft PR up or point me
at a branch I would be happy to try to run this against the simulator
and see if we can get a little further.
This is the simulator I was using https://github.com/sergev/qemu/wiki
I did have to make a few changes to get it to build with a modern
gcc/glibc
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -22,6 +22,8 @@
#include "trace.h"
#include "migration/migration.h"
+#include <sys/sysmacros.h>
+
int open_fd_hw;
int total_open_fd;
./configure --target-list=mipsel-softmmu --python=/usr/bin/python2
--disable-werror
make
Re: Issues with PIC32
Posted by Gregory Nutt <sp...@gmail.com>.
> ... Using
> the pinguino toolchain, 2 LEDs now light up, and the debugger at least
> thinks that we're in the up_idle function, so that looks promising.
> After switching the serial console to UART2(for the explorer16), I do
> now get data out of the serial port! The last message that I see is
> "nx_start: CPU0: Beginning Idle Loop". Nothing else is happening
> though - I was expecting to get some kind of shell, as USER_ENTRYPOINT
> is set to "nsh_main".
That means that the OS bring-up completed without error but something
failed while starting the application. Perhaps the memory is still
configured wrong or perhaps the NSH stack size is too small. It is
impossible to diagnose without debugging.
I would put a breakpoint on nsh_main and see if it gets there.
Re: Issues with PIC32
Posted by Robert Middleton <os...@gmail.com>.
I had been using the pinguino toolchain earlier, but nothing was
happening, hence my switching of compilers to see if anything worked.
With the other compilers, I only got one LED lit up, and at least
according to the MPLABX debugger we were stuck in mm_addregion. Using
the pinguino toolchain, 2 LEDs now light up, and the debugger at least
thinks that we're in the up_idle function, so that looks promising.
After switching the serial console to UART2(for the explorer16), I do
now get data out of the serial port! The last message that I see is
"nx_start: CPU0: Beginning Idle Loop". Nothing else is happening
though - I was expecting to get some kind of shell, as USER_ENTRYPOINT
is set to "nsh_main".
Are there some other options that need to be set to switch nsh to use
the correct UART?
-Robert Middleton
On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> >> * What can I do to debug early boot problems?
> > You can at first try enabling debug output. (make menuconfig -->
> > Build Setup --> Debug Options --> Enable Debug Features). You should
> > have some information regarding what's going on. Another option is to
> > enable DEBUG_SYMBOLS and debug the startup code.
>
> A breakpoint on up_assert should catch any early crashes as you
> describe. There is a cool debug tip here if you hit the breakpoint:
> *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
>
>
Re: Issues with PIC32
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Feb 21, 2021 at 6:13 PM Brennan Ashton
<ba...@brennanashton.com> wrote:
>
> On Sun, Feb 21, 2021 at 3:11 PM Nathan Hartman <ha...@gmail.com> wrote:
> >
> > On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <sp...@gmail.com> wrote:
> > > A breakpoint on up_assert should catch any early crashes as you
> > > describe. There is a cool debug tip here if you hit the breakpoint:
> > > *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
> >
> > Unfortunately that appears to be a broken link now.
>
> It just has a * added to the url this works:
> https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf
Woohoo! Thanks for the correction!
Nathan
Re: Issues with PIC32
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sun, Feb 21, 2021 at 3:11 PM Nathan Hartman <ha...@gmail.com> wrote:
>
> On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <sp...@gmail.com> wrote:
> > A breakpoint on up_assert should catch any early crashes as you
> > describe. There is a cool debug tip here if you hit the breakpoint:
> > *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
>
> Unfortunately that appears to be a broken link now.
It just has a * added to the url this works:
https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf
Re: Issues with PIC32
Posted by Gregory Nutt <sp...@gmail.com>.
>> A breakpoint on up_assert should catch any early crashes as you
>> describe. There is a cool debug tip here if you hit the breakpoint:
>> *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
> Unfortunately that appears to be a broken link now.
Speaking of nuttx.events... Is there any plan for an event this year?
Re: Issues with PIC32
Posted by Gregory Nutt <sp...@gmail.com>.
PIC32are MPS and do not have hardfaults. That is a Cortex-M thing. So
DSidranes tip does not apply and up_hardfault should not exist for
PIC32. I spend too much time with ARMs and a forget about the rest of
the world.
So nevermind... sorry.
On 2/21/2021 5:11 PM, Nathan Hartman wrote:
> On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <sp...@gmail.com> wrote:
>> A breakpoint on up_assert should catch any early crashes as you
>> describe. There is a cool debug tip here if you hit the breakpoint:
>> *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
> Unfortunately that appears to be a broken link now.
>
> However, the cool debug tip that Greg is referring to is, I think, the
> following... (I have this written in my notes from a previous
> hard-fault debugging session.) Note that it is applicable to ARM --
> you may need to adjust for MIPS.
>
> * Set up breakpoints at up_hardfault() and up_assert().
>
> * When the breakpoint is reached, set the PC (program counter
> register) equal to the LR (holds the return address for a function
> call).
>
> * Switch to assembly view.
>
> * Single-step (by assembly instructions) to the "bx lr" instruction
> in do_irq(). That should take you to the line of code where the hard
> fault occurred.
>
> A few more thoughts:
>
> On ARM platforms, one of the common causes of hard faults is
> forgetting to turn on the clocking to a peripheral and then trying to
> access that peripheral.
>
> I haven't worked with PIC32 in a few years but I seem to recall that
> any hard faults I experienced there were caused by unaligned accesses.
>
> Hope this helps,
> Nathan
Re: Issues with PIC32
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt <sp...@gmail.com> wrote:
> A breakpoint on up_assert should catch any early crashes as you
> describe. There is a cool debug tip here if you hit the breakpoint:
> *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
Unfortunately that appears to be a broken link now.
However, the cool debug tip that Greg is referring to is, I think, the
following... (I have this written in my notes from a previous
hard-fault debugging session.) Note that it is applicable to ARM --
you may need to adjust for MIPS.
* Set up breakpoints at up_hardfault() and up_assert().
* When the breakpoint is reached, set the PC (program counter
register) equal to the LR (holds the return address for a function
call).
* Switch to assembly view.
* Single-step (by assembly instructions) to the "bx lr" instruction
in do_irq(). That should take you to the line of code where the hard
fault occurred.
A few more thoughts:
On ARM platforms, one of the common causes of hard faults is
forgetting to turn on the clocking to a peripheral and then trying to
access that peripheral.
I haven't worked with PIC32 in a few years but I seem to recall that
any hard faults I experienced there were caused by unaligned accesses.
Hope this helps,
Nathan
Re: Issues with PIC32
Posted by Gregory Nutt <sp...@gmail.com>.
>> * What can I do to debug early boot problems?
> You can at first try enabling debug output. (make menuconfig -->
> Build Setup --> Debug Options --> Enable Debug Features). You should
> have some information regarding what's going on. Another option is to
> enable DEBUG_SYMBOLS and debug the startup code.
A breakpoint on up_assert should catch any early crashes as you
describe. There is a cool debug tip here if you hit the breakpoint:
*https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
Re: Issues with PIC32
Posted by Abdelatif Guettouche <ab...@gmail.com>.
Hi,
I personally haven't used the PIC32 port in a while, but left it
working. At least the PIC32MZ one.
> Are my assumptions that I should just be able to build and run NuttX
on the explorer16/max32 incorrect?
This could work. However, you have to verify that the configurations
in board.h match your board's. Particularly, you'll have to check the
oscillator frequency, pins mapping, PB clocks, etc.
> * What can I do to debug early boot problems?
You can at first try enabling debug output. (make menuconfig -->
Build Setup --> Debug Options --> Enable Debug Features). You should
have some information regarding what's going on. Another option is to
enable DEBUG_SYMBOLS and debug the startup code.
> Is there a better compiler to use?
Try the pinguino toolchain [1], it's the one we've been trying with.
1. https://github.com/PinguinoIDE/pinguino-compilers
On Sun, Feb 21, 2021 at 4:41 PM Robert Middleton <os...@gmail.com> wrote:
>
> Hi all,
>
> I wanted to test out NuttX and I've run into some very weird issues
> with compiling and running on a PIC32. I don't have any boards that
> are exactly the same as one of the sample configurations, but my
> assumption is that this is not an issue. I currently have two boards
> that I'm testing with: a chipKIT Max32, and an older Explorer 16 from
> Microchip. My starting point is with the pic32mx-starterkit
> configuration in the boards/mips/pic32mx directory.
>
> I've only gotten output on the serial port about two times; all the
> other times it seems as though it panics very early in the boot
> process. One time it seemed to show some kind of memory dump, the
> other time I got a bus fetch exception at address 0x0. Moreover, it
> seems very inconsistent as to when it will actually output anything on
> the serial port - I can recompile what I think is the same
> version(same configuration settings), but running it will result in no
> output.
>
> I've tried using a compiler I built using crosstool-ng, but ld doesn't
> recognize -nostartfiles for some reason. I've also tried using
> Debian's MIPS cross-compiler. The final compiler I tried is a also
> built with crosstool-ng, from this repo[1]. All show the same issue.
>
> * Are my assumptions that I should just be able to build and run NuttX
> on the explorer16/max32 incorrect? I only care about getting a
> console on serial at the moment so I can start messing around with
> things.
> * What can I do to debug early boot problems?
> * Is there a better compiler to use?
>
> -Robert Middleton
>
> [1]: https://github.com/MajenkoProjects/crosstool-ng-pic32