boards/opencm9-04 : initial support #6388

astralien3000 · 2017-01-17T11:08:48Z

Hello !

This is just a work in progress, because I am currently only able to make the custom FLASHER work.
I am not even able to make a led blink...

Here are the best information I can get on this board :
http://support.robotis.com/en/product/controller/opencm9.04.htm

aabadie · 2017-01-17T11:19:21Z

Thanks, this board looks great.

Your port is still missing a board.c and an include directory with a board.h and periph_conf.h. Take example on nucleo-f103 board as they share a similar CPU.

I guess you can keep the same CLOCK definition macros and, from the schematic, configure 1 or 2 UARTs (PA2/PA3 and PA9/PA10). For the user LED, I don't see what's the pin mapping.

astralien3000 · 2017-01-17T11:35:39Z

According to the schematic, the STATUS_LED(GREEN) should be linked with D14, or PB9.
If I link GND and D14 (with an external wire), the led is ON, and OFF otherwise.
I think I configured correctly LED0 in board.h, but if I try to call LED0_ON; or LED0_OFF;, nothing changes.

astralien3000 · 2017-01-18T10:58:47Z

The LED problem seemed to be a linker script broblem. Indeed, the bootloader need the program to begin at an other address thant the default one.
So, I am able to turn ON and OFF the led in the board_init function, but not in main.
Also, as I understand, the "USB serial" is not an UART for the microcontroller, so that, It needs the full USB stack to use this serial.

astralien3000 · 2017-01-19T09:39:32Z

Here is my problem : I can't run the main function because the program has a problem before getting to the main.
I know that I can run the functions :

And I reach the function thread_arch_start_threading which triggers an "svc" interrupt.

And then I don't know where go the execution thread.
As far as I understand, the isr_svc function should be executed, but it is not.

I think the interrupt vector is not found by the microcontroller. Indeed, the board has a bootloader by default, and the user program don't start at 0x08000000 but at 0x08003000 (I use a custom ldscript). So that the vector is not where it should be...

Does someone has an idea on how I can fix this ?

aabadie · 2017-01-19T09:43:06Z

Thanks @astralien3000 for the in-depth diagnosis. Good job !

Does someone has an idea on how I can fix this ?

This is out of my knowledge but maybe @kaspar030 or @haukepetersen can help ?

astralien3000 · 2017-01-19T11:30:13Z

Some good update !
It seems like the error I had was because of this line :

SCB->VTOR = CPU_FLASH_BASE;

CPU_FLASH_BASE is equal to 0x08000000 not depending on what is in the linker script.

If I replace this line by :

SCB->VTOR = 0x08003000;

I can go to the main !
And UART is working !

But it is dirty, and I don't know what would be the clean way to do the same.
Indeed, CPU_FLASH_BASE is a preprocessor defined value, but it should be something like a linker_script defined value. Also, I don't like the name ^^, since we are talking about the vector's address, not the FLASH's begining address.

astralien3000 · 2017-01-19T11:37:53Z

Hmm :

2017-01-19 12:20:30,691 - INFO # �main(): This is RIOT! (Version: 2017.01-devel-512-g3895a-223-55.wifi-inria-saclay.saclay.inria.fr-opencm9-04)
2017-01-19 12:20:33,646 - INFO # *** RIOT kernel panic:
2017-01-19 12:20:33,646 - INFO # DUMMY HANDLER
2017-01-19 12:20:33,646 - INFO # 
2017-01-19 12:20:33,647 - INFO # *** halted.

Why is the dummy handler triggered since there is no dummy handler in the stm32f1's vector implementation ?

aabadie · 2017-01-19T11:45:52Z

CPU_FLASH_BASE is equal to 0x08000000 not depending on what is in the linker script.

Better use this line in the cmsis file. Then you need to create a dedicated one for your board and play with the defines to include the right one.

astralien3000 · 2017-01-19T14:09:36Z

I have done like the spark-core board (modified the VTOR field in board_init).
The interruption triggered is an USB interruption initialized by the bootloader :

2017-01-19 15:04:08,501 - INFO # �main(): This is RIOT! (Version: 2017.01-devel-513-g34e8f-223-55.wifi-inria-saclay.saclay.inria.fr-opencm9-04)
2017-01-19 15:04:08,502 - INFO # Hello World!
2017-01-19 15:04:08,507 - INFO # You are running RIOT on a(n) opencm9-04 board.
2017-01-19 15:04:08,521 - INFO # This board features a(n) stm32f1 MCU.
2017-01-19 15:04:12,037 - INFO # *** RIOT kernel panic:
2017-01-19 15:04:12,038 - INFO # isr_usb_lp_can1_rx0
2017-01-19 15:04:12,038 - INFO # 
2017-01-19 15:04:12,039 - INFO # *** halted.

kYc0o · 2017-01-19T14:11:49Z

Is the bootloader really needed? cannot you overwrite it to start at address 0x08000000 ? What are you using to flash the device?

astralien3000 · 2017-01-19T14:15:09Z

I use the bootloader ^^
There is a SWD/JTAG port, but you need an external JTAG to program/debug the board.

kYc0o · 2017-01-19T14:21:11Z

And which kind of bootloader it has? it's not FTDI or CMSIS-DEP based? (like iotlab-m3 or samr21-xpro)

astralien3000 · 2017-01-19T14:32:05Z

I think it is a custom one, made by ROBOTIS (the board's vendor).
The USB is not a FTDI, but a pure USB that is managed by the controller.
The bootloader seems to have the USB stack implemented, and use it to flash the board.

I use a custom python program (also made by ROBOTIS) to load the code to the board.

astralien3000 · 2017-01-19T14:38:02Z

Good news : I disabled the USB in board_init, and everything seem to work fine.

astralien3000 · 2017-01-19T14:41:01Z

Is the bootloader really needed?

@kYc0o the bootloader is never needed when you have a JTAG, but I had none for the past few days, and it also would oblige people to buy one...

Also, It is possible to handle both configuration : one using the bootloader which need some hacks to work well, and one using the JTAG (2 separate "boards" ?)

kYc0o · 2017-01-19T14:42:14Z

OK I see, then yes you need to change the CPU_FLASH_BASE as you did, be aware of #5636, maybe it can solve this issue. The approach you used is OK but we indeed need a way to abstract this hardcoded address and provide it from somewhere else, for this case and others.

astralien3000 · 2017-01-19T14:48:48Z

be aware of #5636

👍 That would be the way I would implement it ! ^^

Also, I put the linker script in the cpu/stm32f1 directory, which I think is dirty also (the spark-core board do the same). Is there a better way ?

astralien3000 · 2017-01-19T16:36:57Z

Concerning the problem of robotis-loader.py, which has no license header, I added the README from the author's repository, which says that is under MIT.
Is that OK ?

aabadie · 2017-01-19T17:59:27Z

boards/opencm9-04/include/board.h

+/** @} */
+
+/**
+ * @name Macros for controlling the on-board LEDs.


LED: there's only one

aabadie · 2017-01-19T18:02:21Z

Except from a minor cosmetic comment, changes looks good: untested ACK

aabadie · 2017-01-19T18:02:59Z

I forgot: please squash ;)

emmanuelsearch · 2017-01-20T09:17:01Z

I think the standard way is to insert a MIT license header in the robotis-loader.py file, as well as the name of the author.

aabadie · 2017-01-20T14:21:07Z

boards/opencm9-04/Makefile.include

+# custom linkerscript
+export LINKER_SCRIPT = stm32f103cb_opencm9-04.ld
+
+# custom flasher to ust with the bootloader


aabadie · 2017-01-20T14:21:37Z

boards/opencm9-04/Makefile.include

@@ -0,0 +1,23 @@
+## the cpu to build for


aabadie · 2017-01-20T14:22:23Z

boards/opencm9-04/board.c

+    /* initialize the CPU */
+    cpu_init();
+
+    /* initialize the boards LEDs */


I thought you changed LEDs

I thought I did not miss one ;)

aabadie · 2017-01-20T14:23:00Z

boards/opencm9-04/dist/robotis-loader.py

+port = os.environ["PORT"]
+binary = os.environ["HEXFILE"]
+
+# Helper to prints a progress bar


that instead of to is better and keep prints

aabadie · 2017-01-20T14:24:19Z

boards/opencm9-04/include/board.h

+ * @author      Loïc Dauphin <loic.dauphin@inria.fr>
+ */
+
+#ifndef BOARD_H_


Trailing underscores should be removed see #6407

aabadie · 2017-01-20T14:25:53Z

boards/opencm9-04/include/periph_conf.h

+ * @author      Loïc Dauphin <loic.dauphin@inria.fr>
+ */
+
+#ifndef PERIPH_CONF_H_


trailing underscore

aabadie · 2017-01-20T14:27:31Z

boards/opencm9-04/include/periph_conf.h

+#define I2C_1_SDA_PIN       GPIO_PIN(PORT_B, 11) /* D0 */
+/** @} */
+
+/**


You don't want to use SPI and there's a big PR about that #4780. I propose to remove the SPI definitions from this file and the dependency from the Makefile.deps.

aabadie · 2017-01-20T14:54:17Z

boards/opencm9-04/include/board.h

+#define BTN_B1_PIN          GPIO_PIN(PORT_C, 15)
+
+/**
+ * @brief Use the USART1 for STDIO on this board


If you set UART_DEV(0) then, according to the board config, it should be USART2 (not USART1)

Yes, this is what I mean ^^
USART2 is connected to A4 and A5, and to 4-pin communication port (on the robot : the bluetooth module)

USART1 is connected to the Dynamixel TTL bus.

oups sorry, I did not understood

aabadie · 2017-01-20T15:31:18Z

I have problems flashing the board : the flasher code is a bit a mess and not python 3 compatible...

aabadie · 2017-01-20T15:32:55Z

Ok, I think I fixed it

astralien3000 · 2017-01-20T15:40:16Z

Should I modify the script to make it easier to use ? Or is it OK ?

aabadie · 2017-01-20T15:42:02Z

The usage is ok. It's just that it's absolutely not python 3 compatible

aabadie · 2017-01-20T16:34:17Z

@astralien3000 Can you also add some notes about how to flash the board in a README ?

astralien3000 · 2017-01-20T16:40:44Z

Is it better "in the code" or the wiki ?

aabadie · 2017-01-20T16:45:18Z

I think both are ok.

I could test the board with success using examples/default application : I had the shell. Good job !

astralien3000 · 2017-01-20T17:14:02Z

I have added a HOWTO text in the loader, is it ok ?
Well, after that I think I have squashed correctly, don't I ?

aabadie

ACK when CIs are green

aabadie added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jan 17, 2017

aabadie self-assigned this Jan 17, 2017

astralien3000 force-pushed the opencm9-04 branch 3 times, most recently from 51a67d9 to da5bb9f Compare January 19, 2017 16:32

aabadie reviewed Jan 19, 2017

View reviewed changes

boards/opencm9-04/include/board.h

/** @} */

/**

* @name Macros for controlling the on-board LEDs.

Copy link

Contributor

aabadie Jan 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LED: there's only one

aabadie reviewed Jan 20, 2017

View reviewed changes

boards/opencm9-04/Makefile.include

@@ -0,0 +1,23 @@

## the cpu to build for

Copy link

Contributor

aabadie Jan 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 ##

aabadie reviewed Jan 20, 2017

View reviewed changes

astralien3000 force-pushed the opencm9-04 branch from d63b0da to 4c1878f Compare January 20, 2017 15:25

astralien3000 force-pushed the opencm9-04 branch from 813c414 to b6e3c7e Compare January 20, 2017 16:44

astralien3000 added 4 commits January 20, 2017 18:10

cpu/stm32f1: add opencm9-04 specific linker script

480e966

board/opencm9-04: initial support

1fb47b5

tests: add opencm9-04 to insufficient memory boards in some tests

73a3be5

examples: add opencm9-04 to unsufficient memory boards in some examples

5c4bee1

astralien3000 force-pushed the opencm9-04 branch from b6e3c7e to 5c4bee1 Compare January 20, 2017 17:11

aabadie removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jan 20, 2017

aabadie approved these changes Jan 20, 2017

View reviewed changes

aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 20, 2017

miri64 merged commit 5b1c00a into RIOT-OS:master Jan 21, 2017

astralien3000 deleted the opencm9-04 branch February 22, 2017 09:44

aabadie mentioned this pull request Mar 13, 2017

[WIP] Initial commit for Particle Photon support. #6730

Closed

boards/opencm9-04 : initial support #6388

boards/opencm9-04 : initial support #6388

Conversation

astralien3000 commented Jan 17, 2017

aabadie commented Jan 17, 2017

astralien3000 commented Jan 17, 2017

astralien3000 commented Jan 18, 2017

astralien3000 commented Jan 19, 2017 • edited Loading

aabadie commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

aabadie commented Jan 19, 2017 • edited Loading

astralien3000 commented Jan 19, 2017

kYc0o commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

kYc0o commented Jan 19, 2017

astralien3000 commented Jan 19, 2017 • edited Loading

astralien3000 commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

kYc0o commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

astralien3000 commented Jan 19, 2017

Choose a reason for hiding this comment

aabadie commented Jan 19, 2017

aabadie commented Jan 19, 2017

emmanuelsearch commented Jan 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aabadie Jan 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aabadie commented Jan 20, 2017

aabadie commented Jan 20, 2017

astralien3000 commented Jan 20, 2017

aabadie commented Jan 20, 2017

aabadie commented Jan 20, 2017

astralien3000 commented Jan 20, 2017

aabadie commented Jan 20, 2017

astralien3000 commented Jan 20, 2017

aabadie left a comment

Choose a reason for hiding this comment

astralien3000 commented Jan 19, 2017 •

edited

Loading

aabadie commented Jan 19, 2017 •

edited

Loading

astralien3000 commented Jan 19, 2017 •

edited

Loading

aabadie Jan 20, 2017 •

edited

Loading