compiler optimization level nrf api going wrong

[kizhimon]

sdk 17.0.2

IDE - segger embedded studio 

For the below given code, "pin" is not updating when GPIO goes high when optimization level is kept  "Level 3 for more speed". upto "level 2" , "pin" is updating properly.

Could you please let me know why the update is not happening for Level3 optimization ? I added "volatile" qualifier for variable "pin", but still not working

bool pin;

nrf_gpio_cfg_watcher(PIN12);

pin= nrf_gpio_pin_read(PIN12);

[Håkon Alseth]

Hi,

 

I believe the problem is that you are writing and reading the register within a few cpu cycles, where the peripheral clock has not been able to execute in between. This is due to CPU running on 64M and the peripheral clock tree running on 16M. 

Try adding a dummy "peripheral clock wait" and see if this helps:

(void)NRF_TIMER1->EVENTS_COMPARE[0];

 

This will generate a 1 cycle (on the 16M PCLK) between the two calls.

 

Kind regards,

Håkon

[kizhimon]

Thank you Håkon for your reply. It's working when I added that line of code.

Does modifying compiler optimization flag changes CPU frequency ? My understanding is that CPU will be always running in 64 Mhz. Could you please clarify this 

[Håkon Alseth]

The CPU always runs on 64 MHz, but the peripherals are clocked from a 16 MHz clock source:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/clock.html?cp=4_2_0_18_0#concept_rp5_fgp_bs

 

Whenever the cpu interacts with a peripheral register, its always updated on a 16M clock basis. Whenever you read an event, that will cause a wait-state.

The different clock speeds considerations are also mentioned in the migration document from nrf51->nrf52:

https://infocenter.nordicsemi.com/topic/migration_nrf52/MIG/nrf52_migration/functional.html?cp=4_8_0

 

Kind regards,

Håkon

[kizhimon]

Thank you for your reply. I understand it.

1) But why this problem is not happening when optimization level is low (the peripheral still runs at 16M).

2) don't you think these corrections should be included in the SDK driver files?

[Håkon Alseth]

Hi,

 

kizhimon said:

1) But why this problem is not happening when optimization level is low (the peripheral still runs at 16M).

its because no optimization uses more cycles in between configuring and reading the gpio input. 

 

kizhimon said:

2) don't you think these corrections should be included in the SDK driver files?

There are not many cases where this issue of synchronization occurs, as a wait state is introduced whenever you read a event register. Adding a wait-state on all calls will not be efficient.

 

Kind regards,

Håkon

[kizhimon]

thank you