Welcome to Arm Community

I tried adding __IO and the problem has been resolved
But why is the capture_number variable being optimized?

Because the compiler does not know that value of capture_number can change on external event (interrupt), so it presumes it's value will not change unexpectedly.
You can check disassembly code to see what the compiler did, sometimes it will even throw out the code if it thinks it does nothing.

Huijun Yang said:

Keil : V5.28

Compiler : V6.12

Device : ARMCM33

when I use go to definition, "No information avilable for the selected symbol" error occur.

It operate very well in other PC. but, problem occur with only my PC.

I dont know why this issue occur even though I install keil with same method when I installed other PC.

It sounds like the issue might be related to indexing or missing debug information on your specific installation. Since it works fine on another PC, here are a few things you could check: Ensure that your Keil installation path is correctly set in the system variables. Sometimes, missing paths can cause issues with symbol resolution. → If Keil has an option to refresh or rebuild its symbol database, try doing that. → Run Keil as an administrator and see if the problem persists. → If possible, export the working Keil settings from the other PC and import them into your current setup.

I had a similar issue when working on a cross-platform project, and the experts at a flutter app development companies helped me troubleshoot by comparing dependency paths between different machines. Turned out, one of my PCs had an outdated environment configuration

Hi Valentin,

It looks like your custom service tool might have a problem with handling composite device interface and it expects that device contains only custom class interface.

Hi Milorad,

thank you for pointing that out. I've analyzed our source code and found that libusb_open_device_with_vid_pid is used to connect to the USB device. In the case of a composite device two USB devices with identical vid and pid appear. Most likely the function can't handle this situation (although I can't confirm that). Using libusb_open may solve the problem. Since my efforts where made in the context of a prove of concept I'll not further investigate the issue (at least in the near future). I'll eventually post an update at some later instance.

Best,

Valentin