"right" way to override _xt_nmi in IDF?

[cnlohr]

I can't seem to get XCHAL_HAVE_NMI to be set in xtensa_vectors.S... Or at least get it to build on my system. I also have to admit, double-jumping in the NMI to get to my code is less than ideal.

I've added

Code: Select all

CFLAGS+=-DXT_INTEXC_HOOKS

to my makefile and/or component.mk to no avail.

Also tried making a object-specific rule. No dice.

My compile line for that file remains:

Code: Select all

xtensa-esp32-elf-gcc -DESP_PLATFORM -D IDF_VER=\"v2.0-rc1-956-g81f98c0\" -MMD -MP    -I /home/cnlohr/esp/esp-idf/components/freertos/include -I /home/cnlohr/esp/esp-idf/components/freertos/include/freertos -I /home/cnlohr/esp/esp-idf/components/app_update/include -I /home/cnlohr/esp/esp-idf/components/bootloader_support/include -I /home/cnlohr/esp/esp-idf/components/bt/include -I /home/cnlohr/esp/esp-idf/components/coap/port/include -I /home/cnlohr/esp/esp-idf/components/coap/port/include/coap -I /home/cnlohr/esp/esp-idf/components/coap/libcoap/include -I /home/cnlohr/esp/esp-idf/components/coap/libcoap/include/coap -I /home/cnlohr/esp/esp-idf/components/cxx/include -I /home/cnlohr/esp/esp-idf/components/driver/include -I /home/cnlohr/esp/esp-idf/components/esp32/include -I /home/cnlohr/esp/esp-idf/components/ethernet/include -I /home/cnlohr/esp/esp-idf/components/expat/port/include -I /home/cnlohr/esp/esp-idf/components/expat/include/expat -I /home/cnlohr/esp/esp-idf/components/fatfs/src -I /home/cnlohr/esp/esp-idf/components/jsmn/include/ -I /home/cnlohr/esp/esp-idf/components/json/include -I /home/cnlohr/esp/esp-idf/components/json/port/include -I /home/cnlohr/esp/esp-idf/components/log/include -I /home/cnlohr/esp/esp-idf/components/lwip/include/lwip -I /home/cnlohr/esp/esp-idf/components/lwip/include/lwip/port -I /home/cnlohr/esp/esp-idf/components/lwip/include/lwip/posix -I /home/cnlohr/esp/esp-idf/components/lwip/apps/ping -I /home/cnlohr/esp/esp-idf/components/mbedtls/port/include -I /home/cnlohr/esp/esp-idf/components/mbedtls/include -I /home/cnlohr/esp/esp-idf/components/mdns/include -I /home/cnlohr/esp/esp-idf/components/micro-ecc/micro-ecc -I /home/cnlohr/esp/esp-idf/components/newlib/include -I /home/cnlohr/esp/esp-idf/components/newlib/platform_include -I /home/cnlohr/esp/esp-idf/components/nghttp/port/include -I /home/cnlohr/esp/esp-idf/components/nghttp/nghttp2/lib/includes -I /home/cnlohr/esp/esp-idf/components/nvs_flash/include -I /home/cnlohr/esp/esp-idf/components/openssl/include -I /home/cnlohr/esp/esp-idf/components/sdmmc/include -I /home/cnlohr/esp/esp-idf/components/soc/esp32/include -I /home/cnlohr/esp/esp-idf/components/spi_flash/include -I /home/cnlohr/esp/esp-idf/components/tcpip_adapter/include -I /home/cnlohr/esp/esp-idf/components/ulp/include -I /home/cnlohr/esp/esp-idf/components/vfs/include -I /home/cnlohr/esp/esp-idf/components/wear_levelling/include -I /home/cnlohr/esp/esp-idf/components/wpa_supplicant/include -I /home/cnlohr/esp/esp-idf/components/wpa_supplicant/port/include -I /home/cnlohr/esp/esp-idf/components/xtensa-debug-module/include -I /home/cnlohr/git/esp32-cnlohr-demo/main/include -I /home/cnlohr/git/esp32-cnlohr-demo/build/include  -I. -c /home/cnlohr/esp/esp-idf/components/freertos/./xtensa_vectors.S -o xtensa_vectors.o

What is the recommended mechanism for enabling features that are enabled by preprocesor directives? from within the IDF platform?

[cnlohr]

So I can seem to add flags to the command by adding

Code: Select all

CPPFLAGS += -DXT_INTEXC_HOOKS -DXCHAL_HAVE_NMI

Feels kinda dirty.

P.S.

Code: Select all

 make -n 

shows you what would be executed.

[cnlohr]

Ok, I got NMI interrupts firing, but I had to edit xtensa_vectors.S.

I added a preprocessor flag to allow the user code to override all vector code. I couldn't get the _xt_intexc_hooks bits to actually work. Not sure why yet. Is there a reason why we can't just have our own vectors and everything is hidden behind vector code in xtensa_vectors.S? EDIT: It works now, no idea why.

Charles

My code with extra details is as follows:

Code: Select all

	GPIO.func_out_sel_cfg[16].func_sel = 256;
	WRITE_PERI_REG( DR_REG_IO_MUX_BASE +0x4c,  0xa00 ); //GPIO 16 GPIO.

	GPIO.enable_w1ts = 1<<17;
	GPIO.enable_w1ts = 1<<16;


	/* !!!! IMPORTANT BITS HERE !!!! */
	GPIO.pin[0].int_ena = GPIO_PRO_CPU_NMI_INTR_ENA; ///Why can't I set the app CPU?
	GPIO.pin[0].int_type = 3; //Level-change trigger.

	_xt_intexc_hooks[XCHAL_NMILEVEL] = &_my_xt_nmi; //Seems to work now?

	#define ETS_GPIO_INUM 14 //Actually NMI vector.
	intr_matrix_set( 0, ETS_GPIO_NMI_SOURCE, ETS_GPIO_INUM );
	ESP_INTR_ENABLE( ETS_GPIO_INUM );
	/* !!!! DONE IMPORTANT BITS !!!! */

	GPIO.out_w1ts = 1<<16;
	GPIO.out_w1tc = 1<<16;
	GPIO.out_w1ts = 1<<16;
	GPIO.out_w1tc = 1<<16;

	while(1)
	{
		GPIO.out_w1ts = 1<<17;
		GPIO.out_w1tc = 1<<17;
}

[cnlohr]

So summarizing:

Am I doing it right?

Question 2: Someone mentioned not having the stack? That's OK! But it seems the stack is OK in the NMI ISR. Are there corner cases where A1 is not to be trusted?

[ESP_Sprite]

Hm, sounds like a bug, the way I designed the hooks should allow the NMI to be overridden. Will look at it.
EDIT: I see that you're messing with the interrupt in a very manual way. Please use the interrupt allocator instead; you shouldn't have to mess with C flags instead. (Note: Untested - will see if I can give it a go when I'm at the office.)

The higher-priority interrupts can, if I recall correctly, be called during a window overflow or underflow exception, while that exception is spilling the window and has a messed-up A1. I don't know the exact details, but I do know we ran into issues with that.

[cnlohr]

I still think for things like the NMI I should be able to override it, though I do have it working with the _xt_intexc_hooks mechanism now.

Regarding A1: OK! That's just fine. I will have access to a safe buffer when I interrupt anyway.

[ESP_Sprite]

Ah crap, I see now that my high-prio int hook code hasn't made it into esp-idf yet... will give the MR a kick. That'll probably shave a few extra cycles off your NMI handler.