Adding USB Serial

The official STMicroelectronics Arduino core
User avatar
RogerClark
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Adding USB Serial

Postby RogerClark » Sun Sep 25, 2016 8:24 am

Hi Guys

I've started to add USB Serial to the F103C core, but at the moment I'm getting errors because the -Werror=implicity-function-declaration, so I'm not sure whether to remove this compiler option or somehow fix the problem.

The issue is that USBSerial_Rx_Handler() is called from usbd_cdc_if.c, but its not declared in any the include chain for this file.

I've taken a look at what Vassilis did for the HAL MX, and USBSerial_Tx_Handler(uint8_t *data, uint16_t len); is defined in variant.cpp and declared in variant.h

However, as far as I can tell, variant.h is not included into any file which usbd_cdc_if.c includes

My general plan was to declare both

Code: Select all

__weak void USBSerial_Tx_Handler(uint8_t *data, uint16_t len); // This function should be implemented in variant.cpp
__weak void USBSerial_Rx_Handler(uint8_t *data, uint16_t len); // This function should be implemented in variant.cpp


as __weak in hw_config.h and define them in hw_config.c (for want of a better location), and then have the real code for them in variant.cpp, but the STM Core variant.cpp is is not part of the library its part of the variant which is built by the IDE.

But it looks like, either I need to change this compiler warning, or I need to prototype them somewhere that usbd_cdc_if.c includes

I know some of you guys have some experience with using the HAL, so perhaps you can advise (As I may be baking up completely the wrong tree ;0)

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Adding USB Serial

Postby sheepdoll » Sun Sep 25, 2016 5:16 pm

I have spent much of the weekend attempting to get stuff to run on OSX 10.11.6 (El Capitan) With Arduino 6.11. I kept running into issues with usbd_cdc_if.c. Some of which I have been PMing Roger. Was not realizing that we have the same underlying root issue.

In my case I was setting up the project shadow in eclipse (AC6 openSTM32) Eclipse does not allow the direct manipulation of include files. It is somehow supposed to magically index the project and find all includes.

I was able from the Arduino IDE using the Nucleo with the stlink from the old tools and the new ST code to get a simple hardware serial echo sketch to run on the NucleoF103. Apart from it only echos 2 chars then hangs. The texane tool also bricks the Nucleo. The ST supplied OSX down loader does not work. It seems to want to copy to NODE_F103RB in the file system. The Nucleo mounts to the mac as /Volumes/NUCLEO not sure where the node is to come from. This pattern is defined in boards.txt. The download script just passes it through.

To unbrick the Nucleo I have to open a GDB session using the tools in Eclipse which re flashes it. This worked when I build an empty project and ran debug.

When attempting to import one of the HALMX projects eclipse keeps barfing on usbd_cdc_if.c. There is a #define switch in chip.h that includes the variant.h which in turn includes the usb defs. The eclipse pre-processor does not see this #define.

variant.h is dependant on chip.h which is in turn dependent on Arduino.h. My guess is that somehow there is an include on usbd_cdc_if.c that is not part of the Arduino.h path.

I looked at what I did last spring, which was to use a python makefile tool that converts the SW4STM32 .project into a normal makefile. Importing the HALMX project directly using the AC6 importer ignores all the code above the src directory. Adding the missing file via drag and drop to the project does not add them to the local build path. Adding the paths to the CDT through the project "Properties" does seem to bring them into the syntax checker.

Importing the project as a makefile into eclipse seems to create a proper path tree. There seems to be no way to add individual files to the IDE (as one would do in Visual Sudio on the AVR.) Messy that one can not right click a .h file and tell the system the missing path.

In looking at the makefile workspace from last spring (without the usb cdc) the project builds. I notice in the eclipse .project xml that I matched the compiler flags which includes a compiler flag USE_HAL_DRIVER. I also noticed that there may be some F4xx code in the HALMX glue as part of the UDB CDC that i was munging in from Vassillis code base. In theory the HAL low level should be auto generated by STMCube32MX. There are enough slight differences in the upper level HAL API calls that are device specific to be annoying.

This means that the STM32F401xE #define compiler switch and the STM32F103xE (from platform.txt/boards.txt) will have to be checked with #ifdefs. to set up the USB global structures and handlers.

The Arduino IDE builds everything in the folders. So my project builds in the Arduino IDE but I see no data on the serial pins. For all its annoying frustration the eclipse IDE is useful in that it does gray out #ifdef sections that are not seen by the compiler system. This also does mean that there is some underling issue with the way we are including the USB cdc code into the project. Why I am not a big fan of things like abstract operator overwriting and inheritance. Such works well in a language like postscript, lisp or forth which were defined as object oriented in the first pace. IMO these things have no place in C where pointers are exposed and the programmer (not coder) has complete control over the system.

All I want to do is right click on the bleeping object and find the bloody path to it. Not spend all summer setting up a cvs system and a project definition study and power point presentation suitable for a management review.

User avatar
Rick Kimball
Posts: 729
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Adding USB Serial

Postby Rick Kimball » Sun Sep 25, 2016 7:10 pm

My setup is a Nucleo board (actually a Nucleo-f030 nucleo board with all the jumpers removed from the f030) acting as an STLink-V2.1 connected to a blue/red pill. It detects the cortex-m3 and knows what it is. In fact, I can drag and drop compiled .bin files on it and they are flashed to the chip successfully. https://flic.kr/p/JQgmKM

sheepdoll wrote:I was able from the Arduino IDE using the Nucleo with the stlink from the old tools and the new ST code to get a simple hardware serial echo sketch to run on the NucleoF103. Apart from it only echos 2 chars then hangs.

FWIW: I was able to use the Serial1 and Serial2 for the BluePill version of the STM core without a glitch on linux using a Nucleo boards tty port /dev/ttyACM0 pins. Its serial code hasn't been modified from the Nucleo version.
sheepdoll wrote:The texane tool also bricks the Nucleo. The ST supplied OSX down loader does not work. It seems to want to copy to NODE_F103RB in the file system. The Nucleo mounts to the mac as /Volumes/NUCLEO not sure where the node is to come from. This pattern is defined in boards.txt. The download script just passes it through.

When I was first testing the blue pill, I thought I had bricked it. I couldn't connect to it from gdb. It turns out the STM code was disabling the SWD pins. I had to set the boot0 pin to 1 to regain access via gdb. It doesn't look like that is happening to you .. just thought I'd mention it.

In my case the nucleo board shows up as /media/kimballr/NUCLEO .. i didn't actually try the upload feature ST supplies.
-rick
-rick

User avatar
RogerClark
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Adding USB Serial

Postby RogerClark » Sun Sep 25, 2016 8:39 pm

Source to STM's Nucleo upload tool is in the repo, so you could take a look at the code.

The Windows upload script (bat file) is quite hacky, and I intend to replaced it with a better one which uses the Windows WMIC built in exe to search for the Nucleo volume. But I dont have a F1 nucleo at the moment to test this.
( STM tell me they have sent me some boards to test with, but I am currently waiting for them to arrive)


Julie, can you post an Issue to the Tools repo so that the Mac upload issue is logged.


Back to the reason for my post.

I think I may create a WIP branch, as at the moment I wont want to push code that doesnt compile.

I.e., the changes I made locally were just to add the missing USB files, and update the Makefile to pick up the include paths to the "middleware" folder, and also to improve the makefile for windows users ( so it should find the arm compiler installed by the IDE)

But because the makefile instantly adds the USB files and tries to build them, it means I would be uploading things that end up with a broken build process.



Thinking about it again, I will try exporting a clean set of files, with USB CDCACM enabled, from the Cube and confirm it compiles in Alitolic Studio, and take a look at how the application's upper level USB functions are declared, so that hopefully I can replicate the same thing in the STM core's structural architecture.

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Adding USB Serial

Postby sheepdoll » Mon Sep 26, 2016 12:53 am

I am actually working on scripting some of the build process (through ghostscript.) I need a working template first.

Today I compared the working F401 makefile build to one for the F301. Instead of making a new F103 makefile I copied the F401 makefile and changed the references from F4 to F1. From the command line this makes without errors.

I had a lot of issue getting the F103 workspace to accept a makefile. Eclispse just would silently quit. Turns out that the F401 workspace is in a different path tree. Apparently eclipse can not import a project to the same folder as the workspace. This may be why the openSTM32 was attempting to copy all of the core/maple folders. Eclipse seems to for the internal tools copy the files into the hidden directories. This is why editing the original source is not showing changes during the build phase.

Good callout on the SWD pin. I will check that when I am back on the hardware. As noted HW serial out does work. The hangup seems to be in the serialAvailable() function. Some issue with the ST code as the existing code remaps pins to the nucleo. ST does not have this remap table, instead they do a search on the pin table like other Arduino code sorting pin arrays.

In the meantime I am working on new script that creates the makefile with the additional paths directly from the cubeMX based on the .ioc and a hidden file cube creates called .mxproject.

User avatar
RogerClark
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Adding USB Serial

Postby RogerClark » Mon Sep 26, 2016 5:10 am

Just a quick update on the problems with USB.

It looks like the initial problem is being caused because of files created by different versions of the STM Cube.

The files I copied over from Vasillis's work on the HAL MX core don't seem to be totally compatible with the STM Core files, generated by Wi6Labs.

Additionally Vassilis added changed the code in the files generated by the Cube, to add the function to check for the magic number sequence reset via USB Serial.

So I'm now in the process of updating my STM Cube MX, and I will find out from Wi6Labs, which version of the cube they were using.

Looking in the Cube, I think its possible to choose which version of "Firmware" package is installed for each MCU.
However at the moment I'm not sure how you select which on the installed packages to actually use to generate the code. But in the worst case scenario it would be possible just to have one firmware package installer per MCU series.

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Adding USB Serial

Postby sheepdoll » Mon Sep 26, 2016 7:16 am

I got a bit farther along testing on the actual hardware again.

I am using code from Vasillis's code from around march of 2016 which I munged into my fork of the project.

I was able to hand modify the eclipse project to include the correct compiler flags. There are still quite a number of pedantic warnings which indicate that the code is not too stable. Things like missing breaks at the end of case statements. Values not initialized in constructors.

The main issue seems to be in the exported "extern USBD_HandleTypeDef hUsbDeviceFS;" which the compiler claims is never used. Internally there is a variable hUsbDevice_0 of the same typedef which the compiler barfs on and is the main reason usbd_cdc_if.c fails. It looks like some sort of glue is needed to link these two references. This error if it is seems to be an issue with the Hal library as this file is regenerated when ever the cube project code is built.


I sill have one issue with the CDT syntax scanner and utoa. The project includes stdlib.h even though the makfile states -nostdlib. Eclipse will not allow this to be right click deleted. I have not found where in the xml it is defined.
Running make from the command line works just fine. That is all the eclipse build command does anyway. Such adds an extra step.

Took some effort to get the gdb to work. The normal launch fails. launching through Debug configurations works just fine. The code however crashes in an exception handler, where Serial.begin(9600) is called from variant.cpp inside the USE_USBSerial ifdef. The values in these structures seems to be allocated before the HAL_init() is called in main.

I switched the ifdef off. The code then crashes in I2C_init() which is a different issue. I think I still have the old wiring lib in the source tree. I also turned everything on in the STM32CubeMX to see what code was generated.

Not sure about the variations of the Cube firmware library revisions. I noticed that the openSTM32 (Ac6) downloaded the HAL directly into eclipse. My rule (from my days at apple and lib revision hell.) is to use the latest version when at all possible.

I pushed these latest changes to my github fork. The most interesting file is the makefile https://github.com/sheepdoll/HALMX_Arduino_STM32/raw/master/HALMX/variants/MXNucleoF103/Makefile
If the Arduino arm tools path is set in the command line (.profile or what ever .bshrc is called) then make can build the project without any IDE. I used the trick of placing the stub for the .ino into a separate path (I think hard coded in the makefile) to a c++ stub (currently the blinky sketch) I call this folder Arduino_extra and it is where I put things that clutter up the main IDE.

The full path to the git fork is https://github.com/sheepdoll/HALMX_Arduino_STM32.git Only the NucleoF103 has significant changes. There is also a makefile in the NucleoF401 which was my first attempt at a makefile project.

User avatar
RogerClark
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Adding USB Serial

Postby RogerClark » Mon Sep 26, 2016 7:19 am

Thanks

I'll let you know whether I get a response from Wi6Labs about firmware version(s)

User avatar
RogerClark
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Adding USB Serial

Postby RogerClark » Wed Sep 28, 2016 11:28 am

Just a quick update

Wi6Labs have informed me that they use

1.4.0 STM32CubeF1 and the 1.4.0 STM32CubeL4.


So I updated my STM32CubeMX to those versions and removed the other versions I had installed
I've copied the Middlewares folder into the system folder and also added the usb_xx.c and usb_xx.h files to the Src and Inc folders for the libstm32f103c
I also updated the makefile and one of the xxx_conf.h files to enable PCD as this was required by the usb files.

This does compile, But... The resultant library file doesn't run.

I suspect this is because there is other code missing or other xxx_conf.h file changes require
Also, Vassilis's USBSerial Class file (.c) from the HAL MX Core needs to be added to this core (and may have knock on implications for the Nucleo)

However, so that Vassilis (and anyone else thats interested) can take a look, I've created a WIP branch and pushed these changes to that branch.

User avatar
sheepdoll
Posts: 216
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Adding USB Serial

Postby sheepdoll » Wed Sep 28, 2016 6:14 pm

Those libraries are about 2 revisions back. At least they are the versions I have been testing with :)

Was able to make better progress with my build script automator earlier in the week. The working makefile was built by hand using elements from the generated makefile and the board/platform.txt combination. With the automate script, I found that I have been using the wrong F0 definition. The F401 Nucleo uses the RE footprint. The F0 nucleo I have uses the RB Nucleo.

There also quite a few compiler defines in the build script that do not seem to be used by the HAL fork of the project. The one that looks like it could be eliminated for HAL is -DSTM32_MEDIUM_DENSITY. This seems to be used by the maple deep inside the localized hardware code.

There is also a lot of repetition on the flags in the way that I modified board/plaform.txt combination defined flags. -DSTM32F1 and -D__STM32F1__ sometimes seem to be defined more than one on the build line.

I think there are some places in the includes where Vasillis used some of my code as a template and did not change the Guard defines on the include headers. If I remember hazy this was more in the blue pill section which still used the Nucleo project name, rather than the blue pill project name. My ultimate goal is for these scripts to also create the chip and variant source files.

I am also considering deprecating in the build script the redundant -DARDUINO_STM_NUCLEO_F103RB -DBOARD_NUCLEO_F103RB command line defines. These are not generated by STM32CubeMX and only exist in board/platform.txt. the CubeMX code generates -DBOARD_MXNucleoF103 (note the case difference. For when board specific options are used.

The reason I mention this as you seem to be using Vasillis mods to my code. So if the compiler switches are not correct then the HAL files can build using the wrong paths. In some cases there are warning. If the wrong chip designator is defined, the low level code will be created for those registers/peripherals which might be ever so slightly different. There are no compiler errors or warnings in these cases. It may be that HW floating point is included rather than software.

As Arduino expect to define things on the fly when the compiler defines are not set correct then some of the pre main init/allocate code (like that in the offending usbd_cdc_if.c that started this thread.) do not get allocated. Then when the high level C++ initializer gets called there is a null pointer exception as there is no handle (or an uninitialized handle) to the HAL code. As written the Serial.begin(9600) is called on USB before the structures are allocated.


Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest