Skip to main content
MRait.14
MRait.14
Associate II
March 23, 2020
Question

USB/CDC stops working by adding a asm("nop")

  • March 23, 2020
  • 8 replies
  • 4277 views

I have some problems with the USB/CDC communication. I have simplified the problem to the following:

I'm using STM32CubeIDE and I've used CubeMX to configure a new project with STM32H743IIT6. I set up the clock and the USB/CDC device.

The communication works fine at the beginning, but if I add commands, even some asm("nop") before the infinite loop it stops working:

int main(void)
{
 HAL_Init();
 SystemClock_Config();
 MX_GPIO_Init();
 MX_USB_DEVICE_Init();
 asm("nop");
 asm("nop");
 while (1) { }
}

One "nop" is ok, but two or more are bad. I have found, that if the function size exceeds 24 byte, the problem occours.

What can be the problem?

Regeards

Matthias

This topic has been closed for replies.

8 replies

TDK
TDK
March 23, 2020

A better definition of "works fine" and "stops working" is needed. Doesn't seem like your program does a whole lot.

"If you feel a post has answered your question, please click ""Accept as Solution""."
MRait.14
MRait.14Author
Associate II
March 23, 2020

Sorry, I have just tested if I can open a connection to the virtual com port.

With the two nops, the terminal program tells me "internal initialization error". I have tested it with several terminal programs.

TDK
TDK
March 23, 2020

I would debug the program and see if it's hung somewhere or if it enters the main loop okay.

If you're in a position to regenerate your project code in CubeMX, do so. Ensure you're on the latest repository version.

"If you feel a post has answered your question, please click ""Accept as Solution""."
Hamid.Wasti
Hamid.Wasti
Associate II
March 27, 2020

This type of a problem is typically caused by a memory overwrite. You either have a buffer that is too small, code somewhere is writing past the end of the buffer or assembly code not restoring the stack properly.

Look at the following things:

Are the arrays of the correct size?

Look at all memory initialization. Are you giving it the correct size? Are you giving it the correct pointer?

For variables passed by reference, especially structures, are you passing and receiving the same thing?

Are the initialized structures you are defining for your USB descriptors correct? It has been a while since I have done USB software, but if I recall correctly some descriptors require "characters" to be 16 bits long.

And most importantly, recompile EVERYTHING in the project and look closely at ALL warnings and make sure you are 100% certain they are not the tip of an iceberg. Better yet, try and change the code to eliminate them.

Good luck.

Regards,

Hamid

MRait.14
MRait.14Author
Associate II
March 28, 2020

Thank you for your help,

I have already tested if with a "clean"project. Just configuring the clock and the CDC device in CubeMX and the latest repository (1.7). The only lines I have added in the entire project are the asm("nop") .

There are no warnings during compilation.

In the past I have done this in a similar way with older versions of Stm32CubeIde and older Firmware packages and it has worked without these problems.

I will try to test it with another version of the firmware, I will check the buffer sizes and I will check the memory initialization again.

Regards,

Matthias

TDK
TDK
March 28, 2020

Make sure the calls to malloc are succeeding (or replace them with a static initializer).

"If you feel a post has answered your question, please click ""Accept as Solution""."
Piranha
Piranha
Principal III
April 1, 2020

If NOPs break the code, then most likely the code has bugs related to volatile variables, memory barriers and interrupt safety. But that doesn't exclude the other typical suspects - cache management, MPU configuration and multi-threading. Basically everything that ST's code monkeys are incapable of understanding.

MRait.14
MRait.14Author
Associate II
April 3, 2020

I have found the reason for my prolem.

In the function CDC_Control_FS() control requests are handled, but he default implementation of CubeMX does nothig here. The problem is now, when a reqeust needs an anwer, an uninitalized array is sent.

In many cases this works because the content of the memory is something valid, but in some cases it does not work ...

Thank you for your help

Terms & ConditionsAccessibility statement