Hi,

unfortunately when a  function is declared as reeantrant (with CYREENTRANT) it is not possible to watch local variables when debugging. Is there a magic trick to get some more insight into that?

Regards, Bob

Hi Bob,

we are going to investigate this issue.

Were you working with a PSoC 3 or a PSoC 5 when this problem showed up?

If PSoC 5, did you use the Keil uVision or the Creator integrated debugger?

This would be good information to have.

Robert

I used a PSoC3 part wit a Kit001and the Keil-compiler. I cannot switch to a PSoC5 part to test in the next few days.

Regards, Bob

I have to believe this is a PSoC 3 issue - the 8051 stack architecture creates the need for the REENTRANT option. Do let us know if you see the same thing on PSoC 5 - I have been wrong before!!!

What compiler optimizations do you have? I am using level 2 for size and it works OK.

Are you using the Locals window or adding your local to the Watch window? Do you get a message like "The name 'loc' does not exist in the current context"?

- Mark

Using Keil 9,03 Optimization Level 0 (zero) (during Debug)

I used the locals window and when I didn't see any vars, I tried to add a watch, but the name I clicked right on didn't allow for a watch-var. No error-messages as far as I remember. Presumably you are right with the architecture of the 8051 when using reentrant code, but I do need it for a RTOS for PSoC 3. No time this week to test it with a PSoC 5, sorry.

Regards, Bob

I didn't mean to imply there was anything wrong with writing reentrant code on an 8051. There was just a little confusion as to whether you were on a PSoC 3 or a 5. I was just saying that I thought you were on a PSoC 3.

The issue behind this is the small stack size on the 8051 which runs out of space quickly if you pass parameters that way (i.e. the normal C way). To avoid stack overflow the Keil compiler assumes functions are not reantrant and allocates static addresses for them. This is fine and dandy, and quite clever, most of the time but fails badly if your function gets called from ISRs because the variables get corrupted when the ISR fires while you were in that function.

One solution is to change the way all functions are handled but that is a big RAM cost. The CYREENTRANT keyword turns on reentrancy for those functions that use it only. Anyway, you probably know all that and just want to figure out what the debugger is up to... !

What kind of variable is it? A simple int or a struct or whatever? Have you declared it volatile? Can you watch, or see in locals, other variables? I tried this out and had no problems - I am just looking for clues as to what is going on.

- Mark

That is a VERY interesting one: you say showing local vars in reentrant functions under Designer 2.0 for PSoC3 devices work for you - and not for me. I'll have to post a demo - project. Hold on, stay tuned, I'll be back right after the break

Bob

Here we are: set a breakpoint in "Function()" and look at the locals.

Hop you see the same as I do: nuts

Bob

I think we have a defect. I tried a few different ways of tricking the debugger into showing me the locals but the use of CYREENTRANT seems to prevent them from showing up. I can see function arguments, but not locals. You sent a really simple example and my first thought was that the variables were getting optimized out... but it happens even when the locals are absolutely needed.

I have created an internal case to get this addressed. If you need/want to get notification when it is fixed please open a tech support case and refer your contact to "CDT 118339".

-- Mark.