[julianr]

Thanks for the explanation. I managed to change the breakpoint to a earlier (not inlined call) and I fixed the bug I was looking for.

[julianr]

I created the log and I searched for -break-insert however I only found two breakpoints. One at main and the one I set and am seeing in the breakpoint window. Yet I see the posted error and I am not able to debug. I attached the logfile.

Attachments:

You must be logged in to view attached files.

[julianr]

It works now and you also updated the xmclib. This is great, thank you!

[julianr]

Here are the steps to reproduce the issue (based on VisualGDB version 5.5 preview 1 build 3294):

1. Create a new ESP32 IDF project (I selected hello world as basis)
2. rename the main folder to e.g. src
3. add the renamed folder to the top most CMakeList.txt (add the line set(EXTRA_COMPONENT_DIRS “src”))
4. click Reload CMake Project
5. add two components with source and header file
6. click Reload CMake Project
7. select the src as main component
8. add a third component with only header files (no “set(COMPONENT_SRCS )” inside the components CMakeList.txt)
9. click Reload CMake Project
10. The third component is not displayed

I attached a minimal sample project which shows this behavior.

Attachments:

You must be logged in to view attached files.

[julianr]

This works great. Thank a lot!

[julianr]

A option like that would be really helpful. In my opinion the name “main” is misleading since there is the complete application code excluding external libraries (which are then inside the components folder).

All my projects usually have a “src” folder where the application code is stored and then some “lib” or “shared” depending on the project. It would be great if I can keep this setup with a ESP-IDF cmake project.

[julianr]

This is very embarrassing…  😳

Of course that is standard hex notation for integer numbers. But this is what happens when you debug unknown code on a hungover Saturday morning before the first coffee…

The problem is still the same. The USB and SysTick IRQ have the same priority and this means the SysTick based wait function is not working inside the USB interrupt handler. You might want to correct this in your demo code together with the missing USB IRQ handler in the next release.

• This reply was modified 8 years, 9 months ago by julianr.

[julianr]

I got it to work. It was a problem with IRQ priorities. For some reason the SysTick IRQ got a lower priority than the USB IRQ wich means that the delay function was not working since the SysTick IRQ never fired to increase the delay time counter when requested inside a USB interrupt.

I fixed this by replacing the line:

#define  TICK_INT_PRIORITY            ((uint32_t)0x000F)

with

#define  TICK_INT_PRIORITY            ((uint32_t)0)

inside the stm32f1xx_hal_conf.h file. I don’t understand the original define anyway. You define a float value with hex notation (is that even possible) and then cast it into an unsigned integer? Why not define it as a integer constant in the first place?

 

[julianr]

Hi,

I added the interrupt handler you proposed. Sadly the demo is still not working.

The interrupt gets triggered but the PC is not able to enumerate the USB device. The clocking should be fine (I am using the standard settings). The System is running with 72Mhz and the USB with a 1.5 prescaler which should generate the required 48Mhz.

Any Ideas what still might be wrong?

[Author]

Posts