HALMX :: MXBluePillF103C8 Roadmap

The Reset sequence (1) is almost ready.

(1) To program an F103 the Arduino IDE through maple_upload file, sends the DTR control signal and the character string “1EAF” via the CDC USB Serial port to the MCU. If that “Magic pack” is correct, the MCU restarts to the bootloader’s memory start address.

– The USBSerial is ready (known as “Serial“).
– The USB Serial port is appeared as “USB Serial device” in the device manager. I have not tested it on Linux or Mac but is expected to work out-of-the box.
– The USB re-enumerations works.

– The bootloader works and it is the stm32duino bootloader v2.0

There is an option in chip.c file that says:
#define USE_USBSerial

Nice – thanks.

Thanks

You are welcome

Nice work Vassilis

I found a bug. If I connect the usb cable to the usb host (PC), the usb is recognized normally by the host. Then, I give power to the the board from an external source (3.3v).
If I disconnect and then re-connect the usb cable to the STM32, the usb host sees the STM as “unknown device”.
I tried to reproduce the usb code to Atollic TrueSTUDIO and it has the same symptom.
When I use the Keil uVision 5 the code works correctly. Every time I disconnect / connect the STM to the usb host , the STM is appeared correctly in the device manager. I think that happens because the uVision uses its own ARM Compiler. The TrueSTUDIO uses the GNU gcc C/C++ compiler, the same as arduino uses

I did a debugging with TrueSTUDIO and I saw that it sticks in to the HardFault_Handler

void HardFault_Handler(void)
{
/* USER CODE BEGIN HardFault_IRQn 0 */

/* USER CODE END HardFault_IRQn 0 */
while (1)
{
}
/* USER CODE BEGIN HardFault_IRQn 1 */

/* USER CODE END HardFault_IRQn 1 */
}

Vassilis, which version of GCC are you using ?

There were issues in the libmaple core, with gcc 4.9 and I noticed that the bootloader will not run if compiled with 4.9

So perhaps its an optimisation setting issue.

Actually this sounds more like an issue about when PA12 is pulled low.

Perhaps it happens too late, and the USB is already code is already running

Vassilis wrote:I found a bug. If I connect the usb cable to the usb host (PC), the usb is recognized normally by the host. Then, I give power to the the board from an external source (3.3v).
If I disconnect and then re-connect the usb cable to the STM32, the usb host sees the STM as “unknown device”.
I tried to reproduce the usb code to Atollic TrueSTUDIO and it has the same symptom.
When I use the Keil uVision 5 the code works correctly. Every time I disconnect / connect the STM to the usb host , the STM is appeared correctly in the device manager. I think that happens because the uVision uses its own ARM Compiler. The TrueSTUDIO uses the GNU gcc C/C++ compiler, the same as arduino uses

I did a debugging with TrueSTUDIO and I saw that it sticks in to the HardFault_Handler

void HardFault_Handler(void)
{
/* USER CODE BEGIN HardFault_IRQn 0 */

/* USER CODE END HardFault_IRQn 0 */
while (1)
{
}
/* USER CODE BEGIN HardFault_IRQn 1 */

/* USER CODE END HardFault_IRQn 1 */
}

@GrumpyOldPizza
Thanks! I will try that.

The strange thing is that I produced the same code with STM32CubeMX (identical) for uVision and TrueSTUDIO.
The first one works correctly, but the second one has the problem I mentioned earlier.

Try to compile it with gcc and optimization -O1

The problem is temporary solved
I used the debugger in TrueSTUDIO to find out where was the problem.
I found that the problem was at the pointer pDev in file usbd_cdc.c that seems to has invalid/wrong RAM address (?). I temporary put that line in comment and the USB worked as expected !

static uint8_t USBD_CDC_DeInit (USBD_HandleTypeDef *pdev,
uint8_t cfgidx)
{
uint8_t ret = 0;

/* Open EP IN */
USBD_LL_CloseEP(pdev,
CDC_IN_EP);

/* Open EP OUT */
USBD_LL_CloseEP(pdev,
CDC_OUT_EP);

/* Open Command IN EP */
USBD_LL_CloseEP(pdev,
CDC_CMD_EP);

/* DeInit physical Interface components */
if(pdev->pClassData != NULL)
{
((USBD_CDC_ItfTypeDef *)pdev->pUserData)->DeInit();
//USBD_free(pdev->pClassData); //<========================== THIS LINE =============
USBD_free(NULL);
pdev->pClassData = NULL;
}

return ret;
}

Vassilis wrote:The problem is temporary solved
I used the debugger in TrueSTUDIO to find out where was the problem.
I found that the problem was at the pointer pDev in file usbd_cdc.c that seems to has invalid/wrong RAM address (?). I temporary put that line in comment and the USB worked as expected !

static uint8_t USBD_CDC_DeInit (USBD_HandleTypeDef *pdev,
uint8_t cfgidx)
{
uint8_t ret = 0;

/* Open EP IN */
USBD_LL_CloseEP(pdev,
CDC_IN_EP);

/* Open EP OUT */
USBD_LL_CloseEP(pdev,
CDC_OUT_EP);

/* Open Command IN EP */
USBD_LL_CloseEP(pdev,
CDC_CMD_EP);

/* DeInit physical Interface components */
if(pdev->pClassData != NULL)
{
((USBD_CDC_ItfTypeDef *)pdev->pUserData)->DeInit();
//USBD_free(pdev->pClassData); //<========================== THIS LINE =============
USBD_free(NULL);
pdev->pClassData = NULL;
}

return ret;
}

Thanks!

@Slammer: @sheepdoll: could you share me the link of the HALMX_Arduino_STM32 repository with the Makefiles? I got a working CMSIS, HAL, and USB drivers for STM32F072 and would like to add its HAL Driver into HALMX_Arduino_STM32. For testing purposes, I would prefer to use Makefile.

@Vassilis

I’m trying to compile using 1.6.9 (which works fine with the libmaple repo – without any changes)

And I now get this error

arm-none-eabi-g++: error: unrecognized command line option '-CC -mcpu=cortex-m3'

Fixed it

@vassilis do a pull from my repo to get these fixes

The issue, believe it or not… appears to be the tab or spaces in front of the -mcpu !!!

I also changed the master compiler path to use the runtime.tools… variable rather than hard coded

compiler.path={runtime.tools.arm-none-eabi-gcc.path}/bin/

@Roger
I did the PR and I started using the Arduino 1.6.9. Everything works fine now.
I tested the 1.6.9 with HALMX some days ago and I got a mountain of errors/warnings

Cool

The only real error was the problem with the spaces in front of the -mcpu, everything else was just warnings

If you are switching to 1.6.9 (like I have), you can also change the build archive path in platform.txt, the warning tells you exactly what to change, its only on 2 lines in platform.txt so is easy change.

BTW. As the only board that currently works, you could comment you the other boards in boards.txt by putting a # in front of all their settings

I think this may save confusion until the other board variants are working, as there are multiple STM32F103C boards in boards.txt
(you don’t need to delete the variants folders)

I can do this is you want. But not until tuesday

RogerClark wrote:If you are switching to 1.6.9 (like I have), you can also change the build archive path in platform.txt, the warning tells you exactly what to change, its only on 2 lines in platform.txt so is easy change.