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

[RK]

Don't think that RAM allocation tests are going to tell you very much. Simplest thing to do would be to put a debugger on the code and see which error handler or fault handler it's ended up int. Have you tried that?

one possibility is you're overflowing the stack. On the lower memory chip the stack will be close to the end of the heap, and the stack isn't bounds checked, so if you use a lot of it, it's quite easy to corrupt some of your heap or fixed memory, then corrupt the stack and crash. So you could try more stack for a start.

[Roger Clark]

@RK

I've not tried running it in the debugger. That was my next step.

Whats strange is that its not actually crashing.The QFAA the device is advertising name does not seem to be set by the code.

I'm using MBED, and it has a default advertising name "nRF51", which is what I see. So it looks like the MBED function to set the device name is failing on one device and not on the other.

Yes... MBED is a complication as it wraps the SD calls, so I should probably re-code it calling the SD API directly, but its still strange it works on one device and not the other

But as you say, its most likely a RAM issue. I will see if I can moved the stack down a bit.

[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