Got the firmware running?

[Palantir555]

Hey @tidklaas , it's great to see somebody has already figured this out!

I know you have managed to flash a firmware image into the NL6621, but have you actually got something running? Some UART test/blinking LED/anything?

I'm working on porting the NL6621_Standard_SDK to gcc and having some working GNU linker scripts would be a massive help.

Thanks! And once again, nice job! :)

[tidklaas]

Hi @Palantir555,

so far I have only loaded and run some test programs to/from the code SRAM. The UART example just prints a demo string about once a second (and thereby also blinks the LED, as it is connected to the TX line ;) ). Instructions on how to reproduce this can be found here.

As for a linker script, you basically have four SRAM areas. Two are used for data exchange between the CPU and the WiFi component and are unused so far. Then there are 192kB RAM available for code at address 0x10000 (although the first 256 bytes are used by the firmware header). Your vector table needs to be located at 0x10100. At 0x80000 are 96kB intended for data, BSS and stack.

I think I will have to write up what I have figured out about this chip so far and post it on nl6621.net. Maybe I will find some time for it tomorrow.

Bye,
Tido

[Palantir555]

Thanks a lot @tidklaas !

I've been working on a port of the linker script for ROM and resource allocation, but there's still a lot of work to do and I'm not that familiar with writing linker scripts. I'll let you know if I get anywhere.

For the time being, I've got all the C sources in the SDK compiling; I'm worried the .s and .asm assembly sources might be MDK-specific, but I'll look into that later on. Maybe find GCC ports of the files.

Same for the .lib libraries, although we can hopefully get GCC to recognise those.

If you end up writing that documentation about the device, i'd love to take a look :)

JC

[tidklaas]

@Palantir555 the locm3 linker script is split into two parts. The first one here defines the available memory regions and the second part here controls where the linker puts which parts of the binary.

The assembly files seem to be Keil specific, but the code is really simple, so there should be no problem porting them. You might have a bigger problem with the stuff that is not included. I am guessing that the binaries will be linked against some standard CMSIS library for the Cortex-M core peripherals, which is not FOSS. That, and also the non-FOSS uCOS-II, was the reason why I did not bother trying to get the SDK working with a GCC base toolchain.

As for the "documentation", I would not really call it that. It is more like a collection of notes I made along the way, plus some rambling on how to go on. Anyway, I posted it here.

Tido