ESP8266 Community Forum

- Tue May 26, 2015 6:53 am #18489

But the rom int 1 exception handler (_xtos_l1int_handler) lowers the int level before
calling the registered handler:

Code: Select all400004ff:       0060f0          rsil    a15, 0


Do I miss something?

IIRC it does so after masking corresponding IRQ line in the intenable SR, so that this IRQ doesn't happen again until handled, but nesting for other IRQs is possible.

It does mask it on the "virtual" level but it caught me on surprise, that the hardware level was enabled.
When thinking more about that it sounds reasonable for virtual interrupts.
I was used to interrupt handlers to operate with interrupts disabled.

Cal

P.S.
Did you notice the gdb problem with "call" I added in other gdb thread?

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Tue May 26, 2015 4:40 pm #18539 Hi Cal,

Is it possible to provide that information to gdb via config?
Providing XML files via esp8266 seems to waste precious resources IMHO.

Openocd provides the information to gdb, it doesn't need to be in the esp8266 itself.

As far as I see the gdbserver role provides that information and thats openocd for you and the esp8266 for me.

Sorry, I missed a detail somewhere and thought you were using JTAG of some kind. What are you doing? You're writing code that allows esp8266 to be a gdb server for itself, without using the OCD (on chip debug) features?

wDev_ProcessFiq is mapped to (level 1?) interrupt number "0" in the XTOS firmware, preparation of
the register stack frame is done by the xtos1 int1 handler in cooperation with vecbase interrupt vector.

That's interesting. From looking at the RTOS SDK I'd thought the NMI was triggered directly by the WiFi peripheral. I guess if I look closer then I'll find it's triggered somewhere in the level 1 interrupt handler, instead,

Is there any chance you're able to start a list of interrupt number mappings on the esp8266-wiki page? I'll add to it if/when I figure more out.

Angus

- Tue May 26, 2015 11:11 pm #18561

Did you notice the gdb problem with "call" I added in other gdb thread?

Yes.

- Wed May 27, 2015 1:18 am #18573

Sorry, I missed a detail somewhere and thought you were using JTAG of some kind. What are you doing? You're writing code that allows esp8266 to be a gdb server for itself, without using the OCD (on chip debug) features?

No.
Playing. Raw version of c/si/x/hbreak and ctrl-c sometimes running, not ready to publish yet,
Yes. Thats why I aked for a gdb server trace from you to see how gdb multi thread stuff is used on that single
thread bare metal. Would you, ...., please ?

wDev_ProcessFiq is mapped to (level 1?) interrupt number "0" in the XTOS firmware, preparation of
the register stack frame is done by the xtos1 int1 handler in cooperation with vecbase interrupt vector.

That's interesting. From looking at the RTOS SDK I'd thought the NMI was triggered directly by the WiFi peripheral. I guess if I look closer then I'll find it's triggered somewhere in the level 1 interrupt handler, instead,

Is there any chance you're able to start a list of interrupt number mappings on the esp8266-wiki page? I'll add to it if/when I figure more out.

Angus

Can do that but i got the impression that those interrupt numbers are the virtual interrupt numbers
as defined by xtos.
An incomplete list is here (the "interrupt related" numbers)
https://github.com/nodemcu/nodemcu-firm ... /ets_sys.h

That may be different for rtos.

Is the wiki github based with md or would i have to learn just-another-wiki-gui/formatting?

Cal

P.S.
What timezone do you have? For me its MET (GMT +2, Europe, Germany).

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG