Binary from nRF51882_QFAC wont run on QAFF

[Roger Clark]

Hi Guys

I've got a strange problem where a binary that works fine on a nRF51822 QFAC does not run on a QFAA

I know that the difference between these two devices is the RAM size, so I did used some code that malloc's various sizes of memory to determine how much is available and on the QFAA I'm seeing

2304 bytes (allocation in 16 byte steps)

On both devices, because I set the linker (GCC) directive file to specify the device only has 16k memory

MEMORY { FLASH (rx) : ORIGIN = 0x0001C000, LENGTH = 0x24000 RAM (rwx) : ORIGIN = 0x20002800, LENGTH = 0x1800 }

If I change the RAM size in the linker and recompile and re-run on the QFAC I see that it has more memory, as my RAM test returns 19024 bytes

But.. These figures don't tally

i.e 2304 + 16384 does not equal 19024

BTW. I'm using the S130 SoftDevice, and just running a simple application which advertises and accepts a connection (so that I can send serial data to the device)

If I recompile and upload to the QFAA rather than copying the binary that was running on the QFAC, the application does not run correctly

The Advertising data is not getting setup correctly and although I can see the device I can't connect to it using a test app (Light Blue running on an iPad)

So I suspect I have some sort of RAM allocation issue

But at the moment this isnt making any sense to me at all.

BTW. I thought it may be a Programmer issue (I'm using a JLInk) but I've tried reading back the code and it does seem to program both devices the same.

I do have another SWD programmer I could try, but this does look like a RAM issue to me.

Does anyone have any ideas what is going one ?

Thanks

Roger

[Roger Clark]

OK.

I have tried the same code on a different nRF51822_QFAA module (not the WT51822-S2 which I was originally testing with) and it works OK

So this issue does not look like this problem is something to do with the Wireless-Tag WT51822-S2 module.

As far as I can see the only difference between the development module I'm using (which is produced by Waveshare) and the production module which was going to be the Wireless-Tag WT58122-S2 is that the WT51822-S2 does not have a 32khz crystal on the board, so I had to fit an external one.

Its possible that the crystal is not functioning correctly, but without it the code won't even start as it permanently waits for the 32khz pll to start. Hence why I fitted and external crystal

Anyway, I'll mark this as "Answered" and perhaps open another one when I have had chance to investigate the problem

[RK]

you can always change the LF clock source to one of the RC ones and see if the code starts, then you'll know if it's the crystal or not.

[Roger Clark]

Actually, that's what I initially tried to do with the Wireless-tag module, www.wireless-tag.com/.../25.html but I had problems getting it to work off its internal RC oscillator, so as I had some 32khz crystals the easiest option seemed to be to solder the crystal onto the side of the module

Additionally the power consumption of the nRF51822 when in sleep mode is considerably more if it runs on the RC oscillator. So it seemed sensible just to add the crystal to the board onto which the module was going to be attached.

However I can't quite see how a erratic LF oscillator can cause the code to behave so strangely.

I'll check the 32khz osc with an oscilloscope and also compare the schematic www.wireless-tag.com/.../p1a1uufbp4101516341h361qct17i63.pdf to see if the is anything else different

[Roger Clark]

Well...

I'm not precisely sure why this is happening, but the problem was being caused because the LF oscillator was running erratically

Although the external 32.768kHz crystal was attached to the the module. The 12pF capacitors had not been fitted.

Looking on a scope the LF osc looked like it was running, and the startup code to detect the LF PLL returned that we had an LF osc.

But somehow the low signal of the LF osc seems to have caused some issues, which I have yet to track down, but some calls to the softdevice seem to have failed.

I don't really have time to figure out precisely which calls were failing. So either we will fit the crystal and the capacitors or revert back to getting the LF oscillator working via its RC mode.