Added gcc cross-compiler support + Makefile

[notandy]

Greetings,

I couldn't resist and added gcc support to datenkrake firmware. Tested with GNU Tools for ARM Embedded Processors ( https://launchpad.net/gcc-arm-embedded/+download ) and flashed via jtag.

But I'am to dumb to test the lpc on-rom bootloader flasher, maybe you have more luck.

cya

andy

[notandy]

Hi, I updated the pull request and incorporated some fixes, forgot the syscall.c newlib-wrapper, sry.

[nedos]

Hmm I got this. I tried to compile it with @jsnyder's arm-eabi-toolchain.

/var/folders/jw/p9yqfm1d7hq5sry380j1wwxh0000gn/T//cckUw7l6.o: In function __cs3_reset_cortex_m':
(.cs3.reset+0xc): undefined reference to _start' collect2: error: ld returned 1 exit status make: *** [ddk-arm.elf] Error 1

[nedos]

FWIW, i got it to link using THUMB\ Flash\ Release/DieDatenkrake.ld, but the lpc17xx.ld isn't working for me as is. What arm toolchain are you using?

[notandy]

gcc arm embedded toolchain, see first post. There are also builds for mac osx.

I figured out the problem: At the end of the startup code (startup_LPC17xx.S), the _start symbol is called. That function is typically defined inside the newlib libc startup code (libgloss/crt0.so) in the target directory, but your toolchain is kinda barebone and doesn't include startup code at all and only a few multilib targets (--disable-libgloss inside the toolchain build makefile).

I'am not quite sure if newlib will work as expected if the you just skip the libc initialisation, but it could work if you substitute _start on line 147 of ./Base/Core/CM3/DeviceSupport/NXP/LPC17xx/startup/gcc/startup_LPC17xx.S with main:

LDR     R0,=main

[nedos]

Okay, I flashed an image produced by this toolchain using lpcflash and it definitely broke something.

[nedos]

Hmm. Yeah I can't get it to flash properly using lpcflash. Here's a newer binary if you want to try out a "working" binary yourself:

(shasum c1513769dc7a8032c70627337c7b5093da6f7986): http://nedos.net/DieDatenkrake.bin

[rgsilva]

For info: I tried @notandy's suggestion of changing line 147 to point to main instead of _start, but it didn't work. It compiles and links properly with the toolchain specified, but it doesn't work: it just hangs there. The image provided by @nedos works fine.

[devio]

Hi,

can you please send me the output of

hexdump -C your.bin |head -n 20

?

thx,

ths

Ricardo Gomes da Silva wrote:

For info: I tried @notandy's suggestion of changing line 147 to point to main instead of _start, but it didn't work. It compiles and links properly with the toolchain specified, but it doesn't work: it just hangs there. The image provided by @nedos works fine.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

1 bottle of beer on the wall, you take one down, pass it around, 0 bottles
of beer on the wall, you take one down, pass it around, 18446744073709551615
bottles of beer on the wall, ...

[email protected] _ 3072R/0x98459AB6 20B244DE 25378169 3E0597FA CF20D03F 98459AB6
JMP in and find out - x68x71x2Ax50x29x31xDBx89xE1x43x89xD8x81x34x24x05x42
x23x23xC1xE0x02x50x51x53x50x5Ax53x43xCDx80x43x43x39xD8x58x50x7FxF6x40xEBxF3

[rgsilva]

@devio, here you go:

ricardo@pios ~/Projekt/ddk-arm $ hexdump -C ddk-arm.bin | head -n 20
00000000  00 80 00 10 cd 00 00 00  8d 67 00 00 8f 67 00 00  |.........g...g..|
00000010  91 67 00 00 93 67 00 00  95 67 00 00 00 00 00 00  |.g...g...g......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 97 67 00 00  |.............g..|
00000030  99 67 00 00 00 00 00 00  9b 67 00 00 d9 0a 00 00  |.g.......g......|
00000040  9f 67 00 00 9f 67 00 00  9f 67 00 00 9f 67 00 00  |.g...g...g...g..|
00000050  9f 67 00 00 2d 0c 00 00  3d 0d 00 00 b1 0d 00 00  |.g..-...=.......|
00000060  05 0e 00 00 9f 67 00 00  9f 67 00 00 9f 67 00 00  |.....g...g...g..|
00000070  9f 67 00 00 9f 67 00 00  9f 67 00 00 9f 67 00 00  |.g...g...g...g..|
*
000000c0  9f 67 00 00 9f 67 00 00  9f 67 00 00 01 48 80 47  |.g...g...g...H.G|
000000d0  01 48 00 47 61 1f 00 00  b9 09 00 00 00 00 00 00  |.H.Ga...........|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000002f0  00 00 00 00 00 00 00 00  00 00 00 00 10 b5 05 4c  |...............L|
00000300  23 78 33 b9 04 48 10 b1  04 48 af f3 00 80 01 21  |#x3..H...H.....!|
00000310  21 70 10 bd c8 08 00 10  00 00 00 00 98 0b 03 00  |!p..............|
00000320  08 b5 06 4b 1b b1 06 48  06 49 af f3 00 80 06 48  |...K...H.I.....H|
00000330  01 68 11 b1 05 4a 02 b1  90 47 08 bd 00 00 00 00  |.h...J...G......|
00000340  98 0b 03 00 cc 08 00 10  00 00 00 10 00 00 00 00  |................|
00000350  06 4b 1a 68 42 f0 80 60  18 60 19 69 4f f0 80 60  |.K.hB..`.`.iO..`|
ricardo@pios ~/Projekt/ddk-arm $ 

Regards,

Ricardo

[devio]

Hey Ricardo,

Ricardo Gomes da Silva wrote:

ricardo@pios ~/Projekt/ddk-arm $ hexdump -C ddk-arm.bin | head -n 20
00000000 00 80 00 10 cd 00 00 00 8d 67 00 00 8f 67 00 00 |.........g...g..|
00000010 91 67 00 00 93 67 00 00 95 67 00 00 00 00 00 00 |.g...g...g......|

This is the interrupt vector table (entries 0-7). Entry 7 is a special entry and
reserved for the checksum of entries 0 to 6. In this case, the checksum at 0x1C
is 0x00000000 - which is obviously not correct :)

The LPC17 bootloader now assumes, that the user-code is not correct and is
entering the on-chip bootloader (which you refer to as "it hangs" - actually
it's executing bootloader code, not yours).

However, before a binary file can be flashed to the LPC17, you need to execute
some post-linker patching routines that calculates the checksum and patches the
entry at file-offset 0x1C.

The calculation of the checksum is rather simple and specified in the LPC17 user
manual on page 616 (section 32.3.1.1):
http://www.nxp.com/documents/user_manual/UM10360.pdf

I hope this helps - if not, let me know.. unfortunately i don't have written any
python script so far to perform the post-linker patching - but it should be an
easy task :-)

cheers & regards,

Thorsten

1 bottle of beer on the wall, you take one down, pass it around, 0 bottles
of beer on the wall, you take one down, pass it around, 18446744073709551615
bottles of beer on the wall, ...

[email protected] _ 3072R/0x98459AB6 20B244DE 25378169 3E0597FA CF20D03F 98459AB6
JMP in and find out - x68x71x2Ax50x29x31xDBx89xE1x43x89xD8x81x34x24x05x42
x23x23xC1xE0x02x50x51x53x50x5Ax53x43xCDx80x43x43x39xD8x58x50x7FxF6x40xEBxF3

[rgsilva]

I was kinda lazy and decided to google for a code ready to use for calculating the checksum, and I've found this: http://www.lpcware.com/content/nxpfile/lpc177x8x-checksum-insertion-program. Using this against @nedos's DieDatenkrake.bin seems to work fine, giving me the same checksum at 0x1C.

ricardo@pios ~ $ ./a.out Projekt/DieDatenkrake.bin DieDatenkrake-patched.bin
File Projekt/DieDatenkrake.bin loaded with size 177204 bytes
Word 0: 0x20080000
Word 1: 0x000001f9
Word 2: 0x0000020b
Word 3: 0x0000020d
Word 4: 0x0000020f
Word 5: 0x00000211
Word 6: 0x00000213
Word 7: 0xdff7f3bc (cksum total: 0x00000000)
File DieDatenkrake-patched.bin created with size 177204 bytes
ricardo@pios ~ $ diff Projekt/DieDatenkrake.bin DieDatenkrake-patched.bin 
ricardo@pios ~ $

Based on this, I compiled the ddk-arm image and patched with the checksum:

ricardo@pios ~ $ ./a.out ddk-arm-original.bin ddk-arm-original-patched.bin
File ddk-arm-original.bin loaded with size 202832 bytes
Word 0: 0x10008000
Word 1: 0x000000cd
Word 2: 0x00006801
Word 3: 0x00006803
Word 4: 0x00006805
Word 5: 0x00006807
Word 6: 0x00006809
Word 7: 0xeffd771a (cksum total: 0x00000000)
File ddk-arm-original-patched.bin created with size 202832 bytes
ricardo@pios ~ $ diff ddk-arm-original.bin ddk-arm-original-patched.bin 
Binary files ddk-arm-original.bin and ddk-arm-original-patched.bin differ
ricardo@pios ~ $ hexdump -C ddk-arm-original-patched.bin | head -n 2
00000000  00 80 00 10 cd 00 00 00  01 68 00 00 03 68 00 00  |.........h...h..|
00000010  05 68 00 00 07 68 00 00  09 68 00 00 1a 77 fd ef  |.h...h...h...w..|
ricardo@pios ~ $ 

Finally, I flashed it and it's still not working, going straight to the bootloader. Is there anyway to debug it? :)

One thing that I noticed is that compiling the binary image won't give the same as @nedos's. I assume this is because it's a different version.

[devio]

Ricardo Gomes da Silva wrote:

I was kinda lazy and decided to google for a code ready to use for
calculating the checksum, and I've found this:
http://www.lpcware.com/content/nxpfile/lpc177x8x-checksum-insertion-program.
Using this against @nedos's DieDatenkrake.bin seems to work fine,
giving me the same checksum at 0x1C.

Good point! This program looks good...

Finally, I flashed it and it's still not working, going straight to the
bootloader. Is there anyway to debug it? :)

Hm, are you sure you're really executing the bootloader? Have you attached
minicom, picocom or whatever you're using for accessing serial lines and pressed
"?"?

One thing that I noticed is that compiling the binary image won't give the
same as @nedos's. I assume this is because it's a different version.

Maybe minor compiler version differences... doesn't make me wonder...

Have you also checked if you rolled back to your previous version? Previously
you wrote "For info: I tried @notandy's suggestion of changing line 147 to point
to main instead of _start, but it didn't work."

Regards,

Thorsten

1 bottle of beer on the wall, you take one down, pass it around, 0 bottles
of beer on the wall, you take one down, pass it around, 18446744073709551615
bottles of beer on the wall, ...

[email protected] _ 3072R/0x98459AB6 20B244DE 25378169 3E0597FA CF20D03F 98459AB6
JMP in and find out - x68x71x2Ax50x29x31xDBx89xE1x43x89xD8x81x34x24x05x42
x23x23xC1xE0x02x50x51x53x50x5Ax53x43xCDx80x43x43x39xD8x58x50x7FxF6x40xEBxF3

[rgsilva]

@devio, hm, I didn't really check if it was running the bootloader or not. Turns out it's not, it's hanging somewhere else. I wrote ? in the serial line using picocom (-b 115200 /dev/ttyUSB0) and it didn't send me anything back.

And yes, I rolled all changes back, just in case:

ricardo@pios ~/Projekt/ddk-arm-original $ git diff
ricardo@pios ~/Projekt/ddk-arm-original $ 

Regards,

Ricardo

[devio]

Hey,

Ricardo Gomes da Silva wrote:

@devio, hm, I didn't really check if it was running the bootloader or not.
Turns out it's not, it's hanging somewhere else. I wrote ? in the
serial line using picocom (-b 115200 /dev/ttyUSB0) and it didn't send
me anything back.

hm... now this can be anything :( I'd attach a JTAG debugger to see what
happened... You should double check your code, startup-scripts and memory setup.
If you don't want to attach a debugger, you could try to initialize the LEDs and
turn them on in certain exception handler routines.

Unfortunately i'm pretty busy this week and unable to reproduce the behavior and
to debug these issues by myself, but please feel free to ask stuff; i'm trying
to provide support as good as i can.

cheers,

Thorsten

1 bottle of beer on the wall, you take one down, pass it around, 0 bottles
of beer on the wall, you take one down, pass it around, 18446744073709551615
bottles of beer on the wall, ...

[email protected] _ 3072R/0x98459AB6 20B244DE 25378169 3E0597FA CF20D03F 98459AB6
JMP in and find out - x68x71x2Ax50x29x31xDBx89xE1x43x89xD8x81x34x24x05x42
x23x23xC1xE0x02x50x51x53x50x5Ax53x43xCDx80x43x43x39xD8x58x50x7FxF6x40xEBxF3

[rgsilva]

@devio,

Sure, no problem! I started debugging with the LEDs after I figured out how to make them work! :)

I kinda figured out what's the problem. Any call to puts, printf and putchar will hang the execution. I'm still trying to fix it, though.

Btw, I tried both with the toolchain you specified, as well with another one avaiable in AUR (https://aur.archlinux.org/packages/arm-none-eabi/), and in both toolchains I had to change startup_LPC17xx.S, making it point to main instead of _start. Since this is the only way my code gets executed, I'll keep this change around for a while :)

Cheers,

Ricardo

[notandy]

Okay, a new day, a new try.

With JTAG, I was able to locate the problem. There was absolutely no global DATA initialization and BSS zeroing. So some predefined global pointers of the libc were dangling around. I also increased the stack and heap size and moved them to sram.
I updated the code with the last commit. At last, I converted the binary with @rgsilva recommended checksum-insertion-program and uploaded a new binary: https://git.ndyk.de/datenkrake.git/ .

For me, It seems to work after flashing it with @nedos libusb-lpcflash fork. Nevertheless, this means not much, so please, test it :)

[rgsilva]

@notandy Nice job, it worked on the first try! I didn't fully test it, but from what I saw so far it works as expected.

[nedos]

Okay, the binary @notandy uploaded worked for me. However, the project still doesn't build successfully with my arm toolchain. I'm gonna try a handful of things and report back.

@rgsilva: I'm assuming you're still running the same gcc-arm-embedded toolchain as @notandy?

[nedos]

Okay, I can confirm this is working for me now. At least the flashing. I'm going to do a few more tests though.

[nedos]

Okay I'm still having some issues. The binary that I get as a result, but the command line is a bit broken which makes me think that the linker script isn't working for me.

[rgsilva]

@nedos How broken?

[nedos]

I see some debug printfs that are gone in the version I compile with crossworks. Also sometimes the printf returns a line twice, i.e. # in the following example.

Use '<command> ?' for details on parameters to command
# 
# 

[rgsilva]

Oh, that's true. I didn't notice until now.

[notandy]

Okay, hopefully this fixes the I/O bugs you encountered.
I also added a check-sum calculation program that automatically applies the checksum to the generated .bin file, ready to flash :)

[rgsilva]

@notandy Nice! Tested here and it works perfectly (as far as I can tell, at least). The checksum patch also worked like a charm. :)

[jedahan]

was there a reason this wasn't merged?