OpenOCD with ARM on ADSP-SC594 breaks on each interrupt

Moved to CrossCore Embedded Studio and Add-ins community

Hi,

We are looking into this case now. We will get back to you.

Best Regards,

Santhakumari.K

I can say that this SVC interupt of FreeRTOS (using it for task switching) - the other interrupts work.

While there is another issue - Debugging (all on Windows CCES 2.11), the target behaves differently if using "default" JTAG debugging of CCES or using the OpenOCD bridge,

I can not get any driver running with the "default" debugging while the drivers on OpenOCD work (using the drivers of the BSP)

Hello,

Can you clarify what you mean by "direct support" inside CCES? Does that mean that you are using CCES but not debugging with OpenOCD in CCES? So you are using the Application with CrossCore Debugger debug configuration?

Regards,

Chad

Correct - using Entry 1 instead of Entry 2 when opening "Debug As"

Thank you. Have you tried disabling semihosting? The SVC interrupt is used during semihosting so that might be why it is halting so frequently.

Regards,

Chad

Yes, Semihosting is not used.

And: why do I see "undefined debug reason 8 - target needs reset" when using OpenOCD ?

Could you reproduce the issue ?

Can you execute "monitor arm semihosting disable" just to be sure because that is really the only reason this would be happening. I have not reproduced this but our team ran into this when working on FreeRTOS and decided to route I/O to the UART.

The undefined debug reason 8 means that the default debug reason of unknown has not been overwritten by a valid reason to have halted. So essentially the debugger halted but was unsure of the reason.

OK, that works now :-) Unfortunately debugging with "default" debugger still does not :-(

Can you clarify what you mean by "default" debugger because we probably have completely different definitions of what that is?

Thanks,

Chad

Using the first entry in the Debugging options, so the "default" debugging.

The issue is here, that interrupts do not work, e.g. writing a command via I2C, the application pends forever on the semaphore inside the I2C driver. Using OpenOCD, the interrupt handling works fine.

Hello,

Okay, thank you for the additional information. That is not considered the default debugging because the method of debugging is dependent on the processor so we don't put them in any specific order. I wasn't really thinking that was what you were referring to because I thought you were concerned with getting OpenOCD + GDB working. So you will have to turn off semi-hosting for that connection as well but that may not solve your issue based on what you are saying so I will have to investigate more. I would at least try to disable semihosting as shown in this screenshot when creating the debug configuration, and I will look into this more.

Thanks,

Chad

Thanks, yes, that's solved it :-)

I expected something more might be needed but that is great news!

Regards,

Chad