Adding USB Serial

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

__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

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.

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.

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.

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.

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.

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_Ardu … 3/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.

Thanks

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

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.

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.

Hi Julie

I deleted my local repo containing Vassilis’s code and copied in clean code from the cube ( albeit expoted using version 1.4.0 to be compatible with the HAL files originally added by Wi6Labs)

The code in the WIP branch compiles now, but the resultant binary does not run.

I dont like the way the USB code generates loads of warnings about casts from unit8 * to char *
As far as I could tell the warnings were harmless, but I wonder if this has been fixed in later versions of the F1 “firmware” packages that the Cube could use.

Re: Defines

I dont know whats normal for the HAL, so I had not noticed that wi6Labs seem to have done a bit of a mashup with defines from libmaple.

Those defines for MEDIUM DENSITY etc actually are a better construct than what the HAL uses, as it groups together a load of individual MCU model number, which conatain the same internal hardware.

I guess the thing we really need to do, is diff all the HAL files etc in the system folder, against a clean set generated from the Cube ( firmware 1.4.0)

So we know what modifications Wi6Labs did, as I suspect we will need to update to later versions of the Cube files sooner or later, as they already seem several revisions old ( I think some MCUs in the Cube are at 1.5.x)

RogerClark wrote:
I dont like the way the USB code generates loads of warnings about casts from unit8 * to char *
As far as I could tell the warnings were harmless, but I wonder if this has been fixed in later versions of the F1 “firmware” packages that the Cube could use.

Dan

Yes.

Can you post your code, or perhaps zip and upload

I looked at Vassilis’s code, which he added to the HAL, but I was hoping that perhaps we could do this without modifying the files generated by the Cube, but I suspect thats not possible.

If possible could you take a look at the code in the WIP branch, as all I did was add the Middleware folder and the usb_xxx .c and .h files and it looks like this broke the stm32f103c library, as my blink test sketch no longer works on the BluePill after I added those files.

I think I’m going to need to run it in GDB and see if it gets and exception, so I can work out why adding unused source code causes it to crash (or at least not work)

RogerClark wrote:
…
The code in the WIP branch compiles now, but the resultant binary does not run.
…

Thanks Daniel

I’ll try changing platform.txt and see if that fixes is it

RogerClark wrote:Dan

Yes.

Can you post your code, or perhaps zip and upload

I looked at Vassilis’s code, which he added to the HAL, but I was hoping that perhaps we could do this without modifying the files generated by the Cube, but I suspect thats not possible.

If possible could you take a look at the code in the WIP branch, as all I did was add the Middleware folder and the usb_xxx .c and .h files and it looks like this broke the stm32f103c library, as my blink test sketch no longer works on the BluePill after I added those files.

I think I’m going to need to run it in GDB and see if it gets and exception, so I can work out why adding unused source code causes it to crash (or at least not work)

Thank Dan

I’ll try patching those files some time over the weekend.

PS. I think Vassilis said he may have got the USB working; possibly he changed the include path stuff in platform.txt

But I know that he definitely recompiled with a new VECT TAB OFFSET of 0x2000 and was able to get the bootloader to jump to the STM Core code and for it to flash an LED on the BluePill

I have been working on USBSerial in the last 2-3 days. So far, I have managed to make the F103C recognized as CDC from my PC.
Next step is to add the USBSerial library to the new core.

Stay tuned!

Thanks Vassilis.

Appologies for not investigating this myself, but I have been looking at problems on the L476 core.

RogerClark wrote:Thanks Vassilis.

Appologies for not investigating this myself, but I have been looking at problems on the L476 core.

OK

Lets hope it moves to 0x2000 OK

Actually…

I have thought about moving all the files from libstm32f103c into the variant folder, and perhaps change some include paths,

I know compiles will take longer, but its a more flexible approach.

However I don’t know what will need to be changed to make this work e.g include paths etc

RogerClark wrote:OK
I have thought about moving all the files from libstm32f103c into the variant folder, and perhaps change some include paths,

I know compiles will take longer, but its a more flexible approach.

However I don’t know what will need to be changed to make this work e.g include paths etc

Vassilis wrote:RogerClark wrote:Thanks Vassilis.

Appologies for not investigating this myself, but I have been looking at problems on the L476 core.

Good idea

We could change it to a constant. Thats a solution to one of the issues.

With our existing libmaple repo each variant gets a lot more options e.g. upload via USB Serial or via STLink etc, which affect other parts of the build, e.g. how many USARTS are configured, but perhaps moving hw_config.c / .h to the variant folder is enough to handle that as well.

Hi there, please apologise me if my contribution is not useful, I have only occasional time to look at these topics..

As far as I know the position of the vector table shoud be the starting address of the sketch (i.e. 0x08002000 in case of using the v2 bootloader, 0x08005000 in case of using the original Maple bootloader, 0x08000000 in case of using no bootloader).
This address is generally specified in the compiler options through the board definition and set in the MCU’s SCB_VTOR registry during the startup phase, so a question: what’s the need to define a const for it?

Thakns in advance and best, E.

In this core we just specify the offset

So as most people are using the new bootloader, the offset will be 0x2000 – but in the future we will also need to support 0x5000 for the old bootloader as well

RogerClark wrote:In this core we just specify the offset

So as most people are using the new bootloader, the offset will be 0x2000 – but in the future we will also need to support 0x5000 for the old bootloader as well

edogaldo wrote:
Ok, but why not just putting a:
#if !defined (VECT_TAB_OFFSET)
#define VECT_TAB_OFFSET 0x0 /*!< Vector Table base offset field.
#endif /* VECT_TAB_OFFSET */


The USBSerial has been added to the new core https://github.com/Serasidis/cbp_HALMX_2

I decided to use the Code::Blocks for creating the static libraries instead of using the .mk files that includes the new ST repo.
The reason is that I am more familiar with Code::Blocks (thanks to Slammer !).

There are two static libraries:
– libstm32f103c_gcc_rel.a that works on 0x08000000 address for using the ST-Link, Serial and BMP upload methods
– libstm32f103c_gcc_rel_bl.a that works on 0x08002000 address for using the DFU upload method.

I used the BluePill board with generic_boot20_pc13.bin bootloader file.

Both versions (with bootloader and without bootloader) use the USBSerial. The bad thing is that the produced code is too big
21608 bytes FLASH, 9776 bytes RAM.

Anyway. To use it just copy the cbp_HALMX_2 folder into the arduino -> Hardware folder and choose the board you want from Tools -> Board -> HALMX 2

The NUCLEO-F103RB variant is not supported yet.

Vassilis,

Thanks for all your hard work on this enhancement.

I will download it today and test on my RedPill

I am sure a lot of people will be interested to try the STM core once this has been added and fully intergated

You are welcome Roger !

Vassilis

I have taken a quick look, and I think that you have effectively not used a library for the bluepill variant, but are building all the system files and HAL files etc when the Arduino builds the sketch.

Is this correct ?

Roger,

To reduce the compiling time just delete all .c and .cpp files (except syscalls_stm32.c file) from cbp_HALMX_2\halmx_2\cores folder.

Hi Vassilis

Fantastic work.

Compiles and runs fine

I didn’t delete any files as there were less files to compile than on the libmaple core, and the IDE used cached versions of most of the object files.

I’ll need to work out the best way to integrate this into the official STM repo.

PS.
I’m mega busy with work at the moment, so I’m probably not going to be able to move this to the official repo until next weekend.
I’ll also need to take a close look at the code

And… I’ll need to look at the driver installation, because the USB Serial enumerates as the STM Virtual Serial device, which needs a different driver from the Maple Serial one (Though perhaps no driver is needed at all or perhaps STM distribute the driver via Microsoft – I really don’t know at the moment)

Nice !