nRF51 boot-loader SystemInit() function

RE: nRF51 boot-loader SystemInit() function

Phil — Fri, 19 Mar 2021 02:48:47 GMT

Edvin,

The VCC supply in our circuit decays to approximately 420mV when the supply is disconnected. It stays above 300mV for several minutes and decays very slowly. So that is likely to be the issue.

We will test the nRF51 POR after when the VCC is shorted to 0V.

We have many devices with this issue in the field, so it is not an option to add the 1Mohm resistor as suggested

Thanks

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Wed, 17 Mar 2021 00:24:22 GMT

Edvin,

This is an excellent response.

This may be the problem: However, if the supply voltage increases from a few hundred mV instead of zero, POR cannot be ensured, and the chip can enter into an unresponsive state.

We will test for this as you have recommended.

Regarding your other points, have no intention of modifying the SystemInit() function. I just wanted to know what was going on. The while() loop was making me nervous.

We are using a Taiyo-Yuden BLE module, and it is their recommendation to place the functionSetResetXtalFreq_32MHz() in SystemInit(). However, I'll move it to main so the MDK files are not modified.

Thanks

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Edvin — Tue, 16 Mar 2021 10:57:49 GMT

Hello,

I discussed a bit with a colleague of mine, and here is what we concluded with:

You should not modify the MDK files. They are implemented on millions upon millions of devices, and there is nothing indicating that there is a bug here that is causing issues with your bootloader. So don't change anything in the system_nrf51.c. It is used to identify what variant the chip is and execute some code based on this.

I don't know specifically what are located on the addresses that you keep asking about, but it is not relevant. We should look elsewhere for the buggy behavior on your devices.

It looks like you have placed SetResetXtalFreq_32MHz() in the start of SystemInit(). You shouldn't do that. You can place it in the start of main(), after the mdk files (as-is) are done doing what they should do.

For debugging purposes, you can try to toggle a gpio in the start of SystemInit() to see whether the chip is starting at all in the cases where it fails. If you suspect that there may be some layout issues, then you can upload your layout, and we can do a review.

Another thing: When you do your power cycle tests, can you please make sure that VDD is pulled below 0.3V before you power it back on in every test? We know that an incomplete power cycle can lead to unresponsive behavior until a full power on reset is performed.

Another thing that you can try for debugging purposes: You can try to add a 1Mohm pull-down resistor on the SWDIO pin. It may sound a bit contraintuitive, since there is a 13kohm internal pullup, but if the issue is related to the VDD not being pulled low enough during your power cycle testing, this may have an effect.

Some relevant information copy-pasted from another private ticket here on DevZone:

It may be that what you are experiencing is due to a missing reset condition. In the nRF51 series, a power-on-reset (POR) event is triggered when the supply voltage is monotonically increasing from zero (0v) to a valid operating voltage (VDD) in less than 100ms. However, if the supply voltage increases from a few hundred mV instead of zero, POR cannot be ensured, and the chip can enter into an unresponsive state.

If the device is powered up from a voltage other than zero, in rare circumstances, the internal POR circuit may not trigger. This leads to the device entering an unresponsive state. Such a scenario may happen if, for example, capacitors connected to the power supply have not been fully discharged.

The unresponsive state is reset by a valid POR event, such as power cycle (<0.3V). Or an off-chip POR circuit can be added to facilitate the triggering of the POR event under these conditions. As an example of an off-chip POR circuit can be adding 1Mohm resistor between SWDIO/nRESET and GND.

An external 1Mohm pull down on the SWDIO/nReset pin to GND will create an additional source for reset on power up. The drawback is an increased base current of about 2-3µA (VDD/1Mohm).

Can you try in your setup with an external 1Mohm and report back with the results?

Best regards,

Edvin

RE: nRF51 boot-loader SystemInit() function

Phil — Tue, 16 Mar 2021 00:41:26 GMT

Edvin

In Product Anomaly Notice nRRF51822-PAN v3.3 there is:

PAN 78: HFCLK: Software reset does not work properly when 32MHz is used as a clock source.

We are using a 32MHz XTAL. The 32MHz XTAL is selected by writing to UICR register NRF_UICR->XTALFREQ = 0xFFFFFF00; // 32MHz.

In the boot-loader I am sure the 32MHz XTAL is not running, only the 16MHz internal RC HFCLK. Also the boot-loader doesn't issue software reset.

However, are you aware of any problems at Power-on reset or Hardware reset when 32MHz XTAL is selected?

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Mon, 15 Mar 2021 22:29:39 GMT

Edvin,

I have this documentation from the nRF51802-PAN-v1.3. It doesn't tell me much. Specifically it doesn't say what is at those addresses or why these values are being written to them. Our concern is the while() loop. Potentially the code could end up here and loop forever if the value at address 0x4006EC00 does not become 0x0001. I have found when I force this code to execute, them the nRF51 fails to run on every second Power-On Reset.

I am still testing to determine if our code ever gets to this while(0 loop. I have been inserting code to toggle pins P0.17 or P0.19 at various places in the bootloader. So far it doesn't ever get to the while loop. Also tracing through the function is_peripheral_domain_setup_needed() with the values I read from flash using JLink, this function returns false. So maybe this is not the problem. It would be nice to know what is going here.

According Nordic documentation, the nRF51802 is the low-cost variant of the nRF51822. They share the same reference manual. As far as I can tell they have the same peripherals and memory map.

To answer your other questions, we know bootloader doesn't jump to the application because there is no UART comms, the current consumption is high and there is no BLE advertising. I have inserted code in the bootloader to toggle GPIO pins so I know where the code gets to and verified that when the nRF51 fails the boot-loader main() is not called. I got to the point that the boot-loader always gets to the start of SystemInit() but not to the end. So that's why I think it has something to so with these fix-up functions.

I have commented out all these three blocks of PAN fix-up functions and so far the nRF51 has always started Ok. I'm still testing this. Is it ok to remove these three blocks of code?

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Edvin — Mon, 15 Mar 2021 15:16:28 GMT

Hello Phil,

All I know is from the PAN:

So it is related to the RAM access. It looks like it only applies to the nRF51802, so it probably doesn't apply to your chip.

Does the code ever reach this statement? If not, I don't see why we need to worry about this address. I could spend some days trying to figure out who wrote the workaround, and what it points to, but I don't really see the use case if is_peripheral_domain_setup_needed() never returns true.

[quote user="Phil Matthews"]When it fails when have found that the application doesn't run and that the boot-loader main() function doesn't get called.[/quote]

How do you determine this? Lack of advertisements, or do you have some other way of checking whether or not your application is started?

Do you have a way to reproduce this while debugging or monitoring some sort of logs?

RE: nRF51 boot-loader SystemInit() function

Phil — Mon, 15 Mar 2021 00:35:36 GMT

Edvin,

For your information we set UICR register XTALFREQ to select 32MHz XTAL.

NRF_UICR->XTALFREQ = 0xFFFFFF00; // 32MHz

This set in the bootloader with the following code:

void SetResetXtalFreq_32MHz(void)
{

	if (NRF_UICR->XTALFREQ == 0xFFFFFFFF)
	{
		// Enable NVM write access
		NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
		while (NRF_NVMC->READY == NVMC_READY_READY_Busy)
		{ }
		
		NRF_UICR->XTALFREQ = 0xFFFFFF00;			// 32MHz
		
		// Set NVM access to read-only
		NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
		while (NRF_NVMC->READY == NVMC_READY_READY_Busy)
		{ }

		NVIC_SystemReset();					// Changes take effect after reset
	}		
}

This code only runs once, because after XTALFREQ has been set to select the 32MHz XTAL the first if() statement is false. This code is from Taiyo-Yuden.

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Mon, 15 Mar 2021 00:20:27 GMT

Edvin

What is at these addresses in the nRF51822?
0x4006EC00
0x4006EC14

These addresses are in the APB Peripheral address range, however these addresses are not within any of the peripheral instance ranges.

For your information I commented out the line that calls is_peripheral_domain_setup_needed(), to force the code block following it to run.

//if (is_peripheral_domain_setup_needed())       // Force code block to run
{
    if (*(uint32_t volatile *)0x4006EC00 != 1)
    {
        *(uint32_t volatile *)0x4006EC00 = 0x9375;
            while (*(uint32_t volatile *)0x4006EC00 != 1){
            }
}
*(uint32_t volatile *)0x4006EC14 = 0xC0;

After this, we found that the nRF51822 consistently failed to start every second Power-On Reset.

We don't know if this is significant or related to our problem, It may not even be relevant since this is for PAN76 which is for nRF51802, and we are using nRF51822.

I seems odd to me that an address is written to with value 0x9375, then immediately there is a loop checking if this same address is 0x0001. If the memory or peripheral at this address doesn't set all the bits to exactly 0x0001 the code will be stuck in this loop forever.

I know this is done in some peripherals, where the peripheral is written to then a bit is checked for some operation to complete. But usually this checks for one bit, not all bits equal to an exact value.

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Fri, 12 Mar 2021 00:50:59 GMT

Edvin

For your information I traced through the functions called in SystemInit() with the values I read from the flash memory in 0xF0000FE0 - 0xF0000FEC using JLink.:

is_manual_peripheral_setup_needed()
is_disabled_in_debug_needed()
is_peripheral_domain_setup_needed()

All these functions should return false, and so the body of the if() statements should never run.

Also I put GPIO pin toggle output in the body of each if() statement, and verified that these functions always return false.

Do these functions even apply to our device nRF51822, HWID 0084?

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Thu, 11 Mar 2021 23:26:59 GMT

Edvin,

For your information I read some registers from the FICR area using JLink:

CONFIGID 0x1000005C FFFF0084

DEVICEID[0] 0x10000060 FDE42A07

DEVICEID[1] 0x10000064 25254449

The device we are using is nRf51822.

The Hardware ID (HWID) is 0084

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Phil — Thu, 11 Mar 2021 21:39:28 GMT

Edvin,

Thanks for your reply.

We are having problems and we think it may be in the boot-loader.

At Power-On reset about 1 in 30 times the chip fails to start.

When it fails when have found that the application doesn't run and that the boot-loader main() function doesn't get called. We have verified this by inserting code that toggles an I/O pin at various point in the boot-loader.

This only occurs at Power-On rest, not hardware reset (via SWDIO pin) and not with software reset. When the fault occurs, the only way to recover is with Power-on reset.

So far we have narrowed the problem down to the SystemInit() function in the boot-loader. Therefore we would like to understand what is the the intention of the code in the SystemInit() function.

When the code is reading addresses in the range 0xF0000FE0 - 0xF0000FEC it looks like it checking for a chip variant. For example in function is_manual_peripheral_setup_needed(void).

I can read these address using the J-Link adaptor and nrfjprog.exe. The values I read are:

0xF0000FE0 00000001
0xF0000FE4 00000040
0xF0000FE8 0000009C
0xF0000FEC 00000000

Could you also tell us which register is at address 0x4006EC00.

This is a reasonably serious issue for us. You assistance will be greatly appreciated.

Phil Matthews

RE: nRF51 boot-loader SystemInit() function

Edvin — Thu, 11 Mar 2021 12:42:32 GMT

Hello,

Are you experiencing any issues with the bootloader, or is this just something you would like to know?

I guess it has a reason for why it is checking these registers, although I can't say I know by heart what they are checking.

What I can say is that it looks like it is checking some peripherals' power registers, probably just to check whether or not they are turned on. Probably to save some power while sleeping.

Best regards,

Edvin