So far I am in a world of compiler warnings, but slowly making progress.
Happy to trade notes with anybody that is interested.
Just an update:
Everything compiles now, but I’m still having some issues with the linker after switching to an IAR startup script for m0:
Error[Li005]: no definition for “SystemInit” [referenced from C:\Users\IPC-ADMIN\Desktop\IARpixy\Debug\Obj\iar_startup_lpc43xx_m0app.o]
I also had to break out all of the inline assembly into a separate file because IAR doesn’t support MACRO directives inline. Many of the instructions generated warnings and errors relating to not repeating the first operand… for example: ADDS r1,r2 complained unless changed to ADDS r1,r1,r2 … I patched things up as well as I could; hopefully things will still run after I get the linker issues sorted out.
I’m actually generating a hex file now - but it isn’t working on the Pixy yet… I get “error: invalid address range.” when uploading through Pixymon. Still waiting for Digikey to send me my JTAG header so I can try using the debugger.
I’ve uploaded the IAR port in the current (still broken) state - if anybody has advice, I’d be happy to hear it…
I fixed the remaining errors and warnings in the IAR port.
Still getting the “invalid address range” error when I try to upload the firmware using PixyMon. (I’m terrible at rework and couldn’t get the JTAG connector soldered on properly.)
One concern is that the hex file I am generating is larger than when I compiled the code in Keil (~320kb vs ~312kb). Any thoughts on whether this may be causing the problem?
Relevant code in Pixymon…
if (m_chirp.callSync(m_programProc, UINT32(addr), UINTS8(len, m_buf), END_OUT_ARGS,
&response, END_IN_ARGS)<0)
throw std::runtime_error("communication error during programming.");
if (response==-1)
throw std::runtime_error("invalid address range.");
Tracking down the callSync macro leads to common/chirp.cpp … unfortunately the -1 response corresponds to CRP_RES_ERROR which seems like it can be generated from many places. (Now considering rebuilding PixyMon to assist in the debugging…)
The issue does not seem to be caused by the hex file size. I dropped the FAST9 code I’m trying to add and the hex file is now smaller than the beta firmware (244 KB).
Any thoughts on the cause of the “invalid address range” error?
If I wanted to recompile PixyMon from source, any suggestion on tools to install?
Yikes, having just gone through a toolchain conversion (ARM RealView to GCC) I can say that this is difficult. Getting it to compile is probably the easiest hurdle. The linker scripts, calling conventions, memory boundary, and multiprocessor (M0/M4) issues are are hard to track/fix, most of these are runtime issues. I’m not discouraging you (*** you will most certainly go mad ***) but you might want to wait for the GCC port. Do you have a preference for IAR?
see here:
http://cmucam.org/boards/9/topics/4336
and here:
http://cmucam.org/projects/cmucam5/wiki/Building_PixyMon
Well, thanks for the warnings on potential sanity loss… I’ve been trying to decide whether to invest in IAR or Keil in the last couple of weeks and thought attempting a port would be a good way to test the environment, tech support, etc. I’m pretty sure GCC is not the right answer for embedded development if the top priority is to get things working rather than freedom and free beer.
I think my next step is to get the JTAG header on to the board and start trying to load the code over the debugger. The only problem here is that I am terrible at rework and haven’t managed to attach the header yet. I actually destroyed the first header I bought and managed to rip a pad off of the pixy board so I may even need to purchase a new one to make progress.
I was thinking that I might add some extra printf debugging to PixyMon in the meantime to see if I could tease out why my hex file is generating the CRP_RES_ERROR – it appears to me that there are multiple (res = …) exit points where this message could be generated.
Thanks for directing me to the PixyMon README files!
There are plusses and minuses no doubt — GCC vs Keil vs IAR. The intention is that GCC/LPCXpresso is going to be the tool going forward once we get it released — we chose because it works well and it’s free and it has good support from NXP and the community. If you have concerns please share!
But yes, porting over the Pixy firmware was a bigger task than anticipated.