Added platform support for Nucleo-F334R8

[matthiasbock]

Hello,

I implemented platform support for ST's Nucleo board with the STM32F334R8 microcontroller: http://www.st.com/en/evaluation-tools/nucleo-f334r8.html Thought, you might be interested in it.

It compiles and I have confirmed the bootup to booloader_main to be working. Also CAN transmission seems to work. Unfortunately I don't have the client working yet, so I can't verify the overall process to be operational (yet).

Let me know, what you think and if you have change wishes.

Cheers, Matthias

[matthiasbock]

Hi,

I will implement your requested changes shortly and also got the client working now.

Question: Is it intentional, that two different CAN IDs are used, 0x080 and 0x000 ?

$ candump can0
  can0  080   [8]  01 5D A9 73 57 7F 01 02
  can0  000   [8]  03 04 05 06 07 08 09 0A
  can0  000   [8]  0B 0C 0D 0E 0F 10 11 12
  can0  000   [8]  13 14 15 16 17 18 19 1A
  can0  000   [8]  1B 1C 1D 1E 1F 20 21 22
  can0  000   [8]  23 24 25 26 27 28 29 2A
  can0  000   [8]  2B 2C 2D 2E 2F 30 31 32
  can0  000   [8]  33 34 35 36 37 38 39 3A

I got another problem now: I get a fault on the microcontroller when attempting to read the config from the PC with the client, using:

$ bootloader_read_config -i can0 -a

[antoinealb]

Question: Is it intentional, that two different CAN IDs are used, 0x080 and 0x000 ?

Yes. The protocol uses datagram that are split across several CAN frames, and the IDs are used for reassembly. In PROTOCOL.md, you can find the meaning of the CAN ids:

The format of the CAN message ID is :

bits 10..8: 3 reserved bits, set to zero for bootloader frames bit 7: 1 bit for start of datagram bit (1 if first frame in datagram, 0 otherwise) bits 6..0: bits for the source ID

So on the traffic you posted, 0x80 is for the start of a new datagram and 0x00 is for the following frames.

I got another problem now: I get a fault on the microcontroller when attempting to read the config from the PC [...]

That's pretty weird... Do another command work or are they all faulting?

Antoine

[matthiasbock]

I pinpointed the problem to memcpy() and memset(). For some reason they are not fulfilling their corresponding function when invoked in can_datagram.c (line 18) and cmp_mem_access.c (line 8 and line 20). When I replace them with for loops, the CAN communication between client and microcontroller appears to work (firmware flashing not tested yet).

Any idea why this happens? Could it be because I specifically included from

/usr/lib/arm-none-eabi/newlib/fpu

in the Makefile? I had to do so, because libopencm3 is apparently compiled with

-mfloat-abi=hard

aswell and without it I got a linker error

ld: error: ... uses VFP register arguments, ... does not

Interestingly, this is the same error as Travis CI is reporting now.

[antoinealb]

When I replace them with for loops, the CAN communication between client and microcontroller appears to work (firmware flashing not tested yet).

This probably means you are linking against an uncompatible version of memcpy (for example with the soft float / hard float confusion). You should not need to specify manually the linker path, if your environment was setup correctly. How did you install your toolchain?

[matthiasbock]

Thanks, @antoinealb, for the compiler setup fix. The new platform works now. The requested changes are implemented too.

[antoinealb]

Perfect! Looks good to me, so I am merging.