I am responsible for developing auxiliary logic in the nrf51822 and have run aground on an issue which I have not been able to find a solution to on my own so I am going to strive to give you as much information as I possibly can.
To give you some background info on the development life cycle of what I am trying to achieve here, in a nutshell I began my development using the NRF51 eval board which has the NRF51422. For the beginning stages of development I simply fly wired the eval board to my application PCB and used the said setup until we were able to acquire the next revision hardware which features the nrf51822. I used the ble_app_uart example project that comes in SDK 12.3.0 and built on that for my needs.
My application is simple. I have the nrf chip connected to my main micro controller via a UART with two hardware handshaking pins. The main micro controller application features custom low power modes which re-configure GPIO and peripheral pins to appropriate configurations for optimum lowest power levels so the handshaking between the two is necessary to wake up the main processor. The exchange is simple, if the nrf has UART data to send to the main uC it pulses one of the handshaking pins that is an input to the main processor. An interrupt on that uC is fired off a the sight of a rising edge and a routine is triggered to reconfigure GPIO to appropriate states to receive UART data. Sometime later after the main processor is ready, it pulses its own handshaking line which is an input to the nrf to signal that it is ready to receive UART data. I’ve configured an edge triggered GPIOTE interrupt on the nrf side to react to this event. Once it sees it, it flips a flag and unblocks a while (flag is not true) loop right before the part in the code example where data is clocked out via the UART and allows it to proceed. I have also configured one of the timer counters to free run at a 4ms rate in order to set up an emergency kick out of 3 seconds in that while loop in the event that the main processor does not pulse its handshaking line so that we don’t lock up the nrf perpetually.
Now for the issue at hand. To be blunt, all of my timing and flow when using the eval kit with the nrf51422 fly wired to my hardware is immaculate. The interrupt on the nrf side always fires, data is properly clocked out to the main processor, and timing is very consistent throughout. When I load the same project on my new revision of hardware that features the nrf51822 things begin to go south very quickly. Timing is very non-deterministic when compared the initial hardware setup, the GPIOTE interrupt on the nrf only sometimes fires and when it starts to not work, it never ever works again until I reset the chip or power cycle the whole system. One major difference between the first and second hardware setup is that the eval kit nrf51422 operates at slightly less than 3.3v while our application has the nrf51822 operating at 1.8v.
Here is some more info on my environment and configuration:
- SDK: 12.3.0
- SoftDevice on both nrf51422 and 51822: S130 v2.0.1
- nrf51822xxAC (256kb ROM / 32kB RAM )
- IRAM and IROM settings used:
- 51422
- IROM base: 0x1B000
- IROM size: 0x25000
- IRAM base: 0x20001FE8
- IRAM size: 0x6018
- 51822
- IROM base: 0x1B000
- IROM size: 0x25000
- IRAM base: 0x20002000
- IRAM size: 0x6000
- 51422
I am wondering if there are any stipulations that we are not aware of when operating the part at 1.8v or differences in SoftDevices or maybe something with my configuration of the part. I would assume that if something was amiss on that front that the application would never even bother to boot and work in a quasi-functional fashion at all. I am grasping at straws at this point. Thank you for any help and please do let me know if I need to provide more information.
