VisualGDB not finding Olimex Tiny info

[support]

Hi,

Please try the following:

1. Change the firmware to turn on the LED, disable interrupts and wait indefinitely
2. Try programming the firmware using JTAG. If it does not start, unplug the board and plug it back. Does the LED actually turn on after you restart the board?

[jhinkle]

I’m doing a detailed debug to try to resolve my issues.

JTAG is on hold and I’m using the gdbstub+serial

I created a new project – blink led + iot sdk

Below is a portion of the code from BlinkLED.c

static os_timer_t s_Timer;
int s_Tick = 0;

void TimerFunction(void *arg)
{
s_Tick++;

//Uncomment the line below to disable the software watchdog that will restart the ESP8266 system after it spends more than ~1 second stopped at a breakpoint.
system_soft_wdt_stop();

if (GPIO_REG_READ(GPIO_OUT_ADDRESS) & BIT1)
{
gpio_output_set(0, BIT1, BIT1, 0);
}
else
{
gpio_output_set(BIT1, 0, BIT1, 0);
}
}

int user_init()
{
#ifdef ESP8266_GDBSTUB
gdbstub_init();
#endif
gpio_init();

#ifdef ESP8266_GDBSTUB
//#error The LED on the Olimex board is multiplexed with the TXD line used by the GDB stub. In order to use the stub, select a different LED pin below.
#endif
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDO_U, FUNC_GPIO1); //PERIPHS_IO_MUX_U0TXD_U

gpio_output_set(0, BIT1, BIT1, 0);
os_timer_setfn(&s_Timer, TimerFunction, NULL);
os_timer_arm(&s_Timer, 300, 1);

return 0;
}

I changed the led pin to a different pin as shown above. and removed the DOG from playing.

set break point at return from user_init and all works well to that point.

I remove the BP and set it at the s_Tick++; in TimerFunction() and RUN.

BP is hit — run — BP hit … can do this without issue –GOOD!.

I try to see the value of s_Tick to verify the program is running or just resetting.

It appears that the gdbstub has an issue properly emulating the instruction the BP is set to.

I set the BP to the s_Tick and perform multiple RUN/BP break and the s_Tick never changes.

I set the BP to the next line of code … system_soft_wdt_stop(); and s_Tick will increment as expected.

So … it appears you have to be very careful where you set BreakPoints or your BP may introduce execution errors — Please confirm this is true.

 

Another observation — not an issue — just a Be Aware.

When you want to perform a debug run, and your setup is to only flash if code changes, NO BP that are set in the user_init() will be hit because the ESP has already executed past that point … so make sure your BP is set where it can be reached outside on any one-time init calls.

 

Next test …. BlinkLED using RTOS.

Made the change to  PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDO_U, FUNC_GPIO1);  as in the iot sdk.

Set BP in user_init().

BP never hit — GDB times out … error

Changed the BP to the LEDBlinkTask() … same result … BP never hit — GDB times out … error

So … it appears RTOS programs are crashing/lock-up prior to reaching user_init();

Are you aware of any RTOS implementation bugs?

Is YOUR testing of RTOS BlinkLed working?

What can I provide to help resolve the RTOS implementation issue I am encountering?

Thanks

 

• This reply was modified 8 years ago by support. Reason: formating

[support]

Hi,

Perhaps something is wrong with the power supply of your board and it’s constantly resetting itself? We have tried the following project with the gdbstub and were able to step over a breakpoint on the s_Tick++ line:

static os_timer_t s_Timer;
int s_Tick = 0;

void TimerFunction(void *arg)
{
    s_Tick++;
    asm("nop");
}

int user_init()
{
#ifdef ESP8266_GDBSTUB
    gdbstub_init();
#endif
    gpio_init();

    os_timer_setfn(&s_Timer, TimerFunction, NULL);
    os_timer_arm(&s_Timer, 300, 1);
    
    return 0;
}

Can you verify that you get the same behavior with this reduced program? If yes, please try getting an Olimex board. The ESP8266 chips are not very reliable, so it could easily be a strange hardware problem.

[jhinkle]

Does using the gdbstub inhibit the use of os_printf?

I’ve spent 6 hours trying and researching on outputing os_printf();

I see that the gdbstub.c defines it as … int os_printf_plus(const char *format, …)  __attribute__ ((format (printf, 1, 2)));

I have two usb-uart attached to the ESP — one on uart0 — programming and gdb — the other connected to uart1-tx

I get the standard resart and sdk check info coming out uart1 — but nothing else.

I have run the application – not attached to the debugger — having uart0 go to a terminal program — no os_printf info.

Can you please share how to acquire the os_printf() info?

Baudrate in both cases is 74800.

Thanks.

 

[jhinkle]

In reply to your post 7993 – I provided that it was not resetting.

I could place the BP in user_init() and it hits once.

Place the BP on the s_Tick++ and it run and breaks without the value being updated.  I place the BP after the s_Tick++ and it get incremented.  That is why I stated it appears to be an issue with the instruction simulation associated with the BP.

I will try your code shortly.

Thanks.

 

[jhinkle]

I took your code and added a “kill the dog” to it.

During the filming I focused more clearly on the behavior and it is NOT as I have stated in earlier posts…. close not not exact.

Please see the video of the issue — link below.

I hope this shows and clarifies the issue I am experiencing

https://www.youtube.com/watch?v=PPJfQa8uuV4&feature=youtu.be

Please let me know your thoughts on this.

Thanks

 

[support]

The link shows “the video is private”. Did you manage to get the code we sent working without any modifications?

[jhinkle]

Youtube added an extra “Publish” step which I did not do — the link should be good now.

I took your code — changed the timer to 500 msec vs 300 and added a “kill dog” to the timer so that the system would not perform a dog reset when a BP was hit and not processed timely.

The video shows the BP issue.  The video shows the tick not incrementing.

You did not reply to me question about os_printf using VisualGDB.  Does it work?  If so — how do you get it to function?  See post 7994.

Thanks

[support]

Hi,

Thanks for the video. The problem might be related to the one of the changes you made. To double-check that please try running exactly the code we provided, without disabling the watchdog and with exactly the same period.

If you can confirm that it does not work, the problem is in the hardware. If it starts working after removing watchdog-related code, the problem is related to the watchdog.

Regarding os_printf(), the gdb stub does support that. VisualGDB currently displays the output from the stub in the GDB Session window together with the other gdb output (you need to select “All GDB interaction”). We will support displaying it separately in the next major release of VisualGDB.

[jhinkle]

I ran your example EXACTLY as you provided and the behavior is exactly as shown on the video.

Your post states that it is a hardware issue — that answer puzzles me as the only hardware involved is the ESP-03 and it is working.

The GDBstub is software and it appears to be working — so what hardware? — The ESP-03?

Here is the GDB session information from the test. Well I tried — your session window does not allow a copy to take place.

What do you suggest the issue is?

 

[jhinkle]

Thanks for letting me know how to get os_printf to display.

I changed the timer to fire 10 seconds and print the value of s_Tick when the timer fired.

Reflashed and the ESP works as expected — timer fires and s_Tick is incremented.

You have not replied to my previous post yet .. so I don’t see a hardware issue — it appears to be a GDB issue:

GDBstub issue?

GDB issue?

VisualGDB issue?

 

The code works as expected when there are no breakpoints set.  The BP is changing the run behavior.

 

[jhinkle]

VisualGDB behavior bug?

I took my program as noted above and commented out gdbstub_init();

This should remove all VisualGDB debugging capabilities.  Indeed – VisualGDB issues a dialog asking if debugging is wanted since it sensed that gdbstub_init() is not being called.

My intent was just to have VisualGDB compile and flash the ESP and then relinquish control — that’s what I hoped for and expected to happen since VisualGDB already noted that the gdbstub was not being called.

Bug??? — After flashing was completed … VisualGDB defaulted right into debug mode and complained that the debug session had a communication issue and timed out.

May I suggest a change to VisualGDB’s behavior … since it knows no debugging can take place prior to flashing the target — DON’T proceed blindly into using GDB to connect to a tartget that it already knows can’t communicate.

Thanks.

 

[jhinkle]

Followup:

I believe the gsbstub has an issue.

I used gdb directly — VisualGDB not open — and set a breakpoint on the NOP and asked to display the value of s_Tick.

The time between the execution of the NOP instruct (Timer is set to 10 seconds)  is 10 seconds yet once the BP is set … gdb returns from the continue in less than 2 seconds (at the NOP instruction) with the value of s_Tick unchanged just as shown in my video.

Is anyone aware of an issue setting a BP inside of a Timer function?

Thanks in advance for any reply.

 

 

[support]

Hi,

Yes, the gdb stub sometimes produces strange results. Generally the ESP8266 is much less stable than the ARM devices like CC3200, albeit much less expensive.

We would recommend trying to get JTAG to work if the gdbstub does not work. We have just released a new toolchain version that improves the JTAG debugging stability by resetting some of the registers that interfere with debugging. Please try using it and let us know if it works.

[Author]

Posts