DPPI_PRESENT functions in modules/hal/nordic/nrfx/hal/nrf_gpiote.h questions.

[Burt]

Hi, I have two concerns about the functions nrf_gpiote_subscribe_set, nrf_gpiote_subscribe_clear, nrf_gpiote_publish_set, and nrf_gpiote_publish_clear. The expression

 *((volatile uint32_t *) ((uint8_t *) p_reg + (uint32_t) event + 0x80uL))

Given pointer arithmetic, the 0x80uL is the same as numerically adding 0x200 to the other terms. However, the Product Spec shows an offset of 0x180, rather than 0x200. I am confused therefore why the number in the code is not 0x60uL. Am I missing something?

Also, I want to put together some code that will publish an event from a gpiote pin changing state, to be subscribed by a timer. In addition to my concern about the functions' correctness, I have not seen any examples of them being used in the SDK. I don't know if that means I am on the wrong track, or that this is something that has not been done frequently.

Thanks for help.

Regards,

Burt Silverman

[Håkon Alseth]

Hi,

 

I have two concerns about the functions nrf_gpiote_subscribe_set, nrf_gpiote_subscribe_clear, nrf_gpiote_publish_set, and nrf_gpiote_publish_clear. The expression

 *((volatile uint32_t *) ((uint8_t *) p_reg + (uint32_t) event + 0x80uL))

Given pointer arithmetic, the 0x80uL is the same as numerically adding 0x200 to the other terms. However, the Product Spec shows an offset of 0x180, rather than 0x200. I am confused therefore why the number in the code is not 0x60uL. Am I missing something?

The event that comes in is of this enum:

https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/hal/nrf_gpiote.h#L241-L254

The function _publish_set, that includes the line that you mention:

https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/hal/nrf_gpiote.h#L846-L847

 

And here is the register definition for nRF9160:

https://docs.nordicsemi.com/bundle/ps_nrf9160/page/gpiote.html#d558e398

 

It takes in an event, lets say (EVENTS_IN[0] + 0x80) = PUBLISH_IN[0] and writes to this register.

Also, I want to put together some code that will publish an event from a gpiote pin changing state, to be subscribed by a timer. In addition to my concern about the functions' correctness, I have not seen any examples of them being used in the SDK. I don't know if that means I am on the wrong track, or that this is something that has not been done frequently.

There is a couple of cases on this matter here in devzone, for instance in this thread:

 GPIO event shall increment counter without CPU 

 

Let me know if you run into any issues!

 

Kind regards,

Håkon

[Burt]

Hi Hakon,

Sorry I was not very sharp with my pointer arithmetic: now I see that p_reg is cast as a pointer to uint8_t so the offset of 0x80uL is obviously correct for the two subscribe functions. However, looking at the register list you pointed to, again, the PUBLISH_IN registers are at offset 0x180. But the offset in nrf_gpiote.h is shown as 0x80 for both the two subscribe functions and the two publish functions. Isn't that a bug in the publish function definitions? Maybe people are using other functions and that's why there hasn't been a problem? (I will find out as I try examples in the code you pointed me to.)

I appreciate the link you sent GPIO event shall increment counter without CPU: that wil be tremendously useful.

[Håkon Alseth]

Hi,

 

Burt said:

However, looking at the register list you pointed to, again, the PUBLISH_IN registers are at offset 0x180. But the offset in nrf_gpiote.h is shown as 0x80 for both the two subscribe functions and the two publish functions. Isn't that a bug in the publish function definitions?

Not sure I understand. For nrf_gpiote_subscribe_ functions, you take in the type nrf_gpiote_task_t, which is a offsetof the TASKS_OUT/SET/CLR, which starts from 0. Add 0x80 to this, and you get the SUBSCRIBE_OUT/SET/CLR register.

enum type nrf_gpiote_event_t is a offsetof() the EVENTS_IN[] events, so it will be 0x100 + 0x80 for the first entry, resulting in reading/writing to register PUBLISH_IN[].

  

Kind regards,

Håkon

[Burt]

Sorry, Hakon, I need to work harder at reading carefully; I am embarrassed!

Another question, is there any way you have time to update timed_signals_ncs240 for ncs302, or is that an exercise I need to do? It looks like the low level drivers change pretty quickly!

Regards,

Burt

[Burt]

Hello Hakon,

I think I have done the job of updating ncs240 for ncs302. There was a small bump at v2.5 and a large one at v2.6, and then no changes were required to get code that at least builds on v3.0.2. I have not tested anything operationally, and I have a few ugly spots that I need to look at. I thought I would let you know what I have been up to.

Regards,

Burt

[Håkon Alseth]

Hi Burt,

 

Glad to hear that the porting is going along nicely. Let me know if you run into any issues or have any problems. I wish you a wonderful weekend!

 

Kind regards,

Håkon

[Burt]

Hakon,

I would like to have a very good hint for how to enable nrfx logging. It seems like I can add

#undef NRFX_MODULE_CONFIG_LOG_LEVEL
#define NRFX_MODULE_CONFIG_LOG_LEVEL 4

to zephyr/modules/hal_nordic/nrfx/nrfx_log.h and CONFIG_LOG=y to my prj.conf. But there are lots of AI hallucinations when I google search and then I come up with things such as 

Enable nrfx Specific Logging.

To enable logging for specific nrfx drivers, you will need to add corresponding Kconfig options to your prj.conf file. The exact option depends on the nrfx driver you wish to log. For example, to enable debug logging for the nrfx_uart driver, you would add:

Code

    CONFIG_NRFX_UART_LOG_LEVEL_DBG=y

Replace UART with the relevant peripheral (e.g., SPI, I2C, GPIO) to enable logging for other nrfx drivers. You can also set a lower log level if desired (e.g., INFO, WARN, ERR).

That does not allow me to build. I would like to know the whole story and I will add that to my notebook/cheat sheets for future reference. 

Thanks,

Burt