LPC4357 - USB_CDC implementation (USB_Configuration stuck)

[lpcware]

Content originally posted in LPCWare by sixten11 on Thu Nov 12 02:34:57 MST 2015
Hi

I've run into a strange issue which is kind of hard for me to explain. Please keep in mind that I'm very new to this. I've implemented the USB_CDC example on my development board, which runs FreeRTOS. I'm using the same USB cable for power as well as for the serial connection (TerraTerm or similar) if that makes sense.

Threads (2 of them) are created via. xTaskCreated and both er called - tested by printing to the I/O, but this line:

while (!USB_Configuration);

In my USB thread hangs forever, if I do not insert a sprintf or similar.

So to sum it up:

This works:

while (!USB_Configuration) { sprintf("anything.."); }

This does not work:

while (!USB_Configuration);

What could be causing this? The sprintf does something that magically makes it all work.

[lpcware]

Content originally posted in LPCWare by vtw.433e on Thu Nov 12 13:41:07 MST 2015
This FAQ gives a good description of various optimisations the compilers make
https://www.lpcware.com/content/faq/lpcxpresso/compiler-optimization

[lpcware]

Content originally posted in LPCWare by sixten11 on Thu Nov 12 12:24:15 MST 2015

---

Quote: djrose
Yes.  A simple optimization most compilers can do is look at the logic flow of a program. If it thinks that a program loop is not writing to a variable, it can simply read once into a register and then keep testing the register (/copy) instead of reading from a memory location.

But, of course, if you have some other action or task that is writing to the variable, you need to give a hint to the compiler to let it know that something else might access it. That is what the volatile basically does.  It tells the compiler to re-read the variable from memory each time it is accessed within your program.

Your original loop with the sprint would normally work because the compiler loses track of the variable it read into a register, and next time it accesses the variable, it re-reads it from memory.

Simples  :bigsmile:

---

Amazing :) thank you very much!

[lpcware]

Content originally posted in LPCWare by djrose on Thu Nov 12 12:05:14 MST 2015
Yes.  A simple optimization most compilers can do is look at the logic flow of a program. If it thinks that a program loop is not writing to a variable, it can simply read once into a register and then keep testing the register (/copy) instead of reading from a memory location.

But, of course, if you have some other action or task that is writing to the variable, you need to give a hint to the compiler to let it know that something else might access it. That is what the volatile basically does.  It tells the compiler to re-read the variable from memory each time it is accessed within your program.

Your original loop with the sprint would normally work because the compiler loses track of the variable it read into a register, and next time it accesses the variable, it re-reads it from memory.

Simples  :bigsmile:

[lpcware]

Content originally posted in LPCWare by sixten11 on Thu Nov 12 11:33:19 MST 2015

---

Quote: djrose
I'd say that the variable USB_Configuration is not volatile.

---

Very interesting! That actually worked. Is this an optimization feature, the loop evaluating to something else (eg. while (1))?

[lpcware]

Content originally posted in LPCWare by djrose on Thu Nov 12 08:11:00 MST 2015
I'd say that the variable USB_Configuration is not volatile.