Search results for:

Was there ever a resolution to this ? We are seeing a similar on the nrf52840 based RAK5010.

It is a hard crash of some kind, no errors shown and takes a reset to fix.

Currently it is happening on a RAK5010 in one location and not another, so we are trying to establish if it is related to certain BLE advertisements

ok, that could explain why some care needs to be taken around serial and BLE at the same time. IT is strange that my code works fine on the RAK8212 (NRF52832), so there must be something subtlety different. @Gordon would implementing UARTE mode ever be on the roadmap ?

With further testing I have found that I still cant get reliable transfer of 22kb from the BG96 to NRF52840 (RAK5010).

But what does seem to help (needs more testing) is for me to pause all BLE operations ie disconnect from the IDE and also pause the BLE scans I am doing in my code.

The NRF52840 has a second serial port, so I might set that up for the IDE

So what I found is if I reduce the baud rate to 9600 then it is stable enough for my 22kb file to download without corruption as it is transferred over the serial port. Does not seem correct though to need to go this slow on a hardware serial port ?

I am a bit stuck on this one, as I can generate the UART_OVERFLOWS with small amounts of data being sent on a 1 sec interval. And as this error is coming from the bottom layers of Espruino it is a little hard to debug.

In the meantime I am going to drop the baud rate back to 19200 and see if I can get a file transfer from BG96 to NRF working with flow control.

But I would love to get to the root of this problem

I am having an issue with UART_OVERFLOW errors on the RAK5010 comms with the BG96

You see at the end of the below commands the QNWINFO response from the BG96 is missing some characters. (But the issue happens in random places, not just there). If I slow the baud rate from 115200 to 19200 the problem pretty much goes away until I start using the BG96 to download a 22kb file from a server, then I get overflows again - although in this case it might be the 19200 is not fast enough to keep up.

Using the same code on a RAK8212 (which defaults to 115200) I dont get overflows (although I have not tried the file download on that)

In theory I have enabled the CTS control on the BG96 so with the commands below there should never be an overflow ? Any ideas ?

["AT+CSQ\r\n"
] "\r\n+CSQ: 19,99\r\n\r\nOK\r\n"
["AT+CEREG?\r\n"
] "\r\n+CEREG: 0,1\r\n\r\nOK\r\n"
Send to server
["AT+QHTTPCFG=\"contextid\",1\r\n"
] "\r\nOK\r\n"
["AT+QHTTPCFG=\"requestheader\",1\r\n"
] "\r\nOK\r\n"
["AT+QIACT?\r\n"
] "\r\nOK\r\n"
["AT+QICSGP=1,1,\"iot\",\"\",\"\",1\r\n"­
] "\r\nOK\r\n"
["AT+QIACT=1\r\n"
] "\r\nOK\r"
["AT+QIACT?\r\n"
] "\n\r\n+QIACT: 1,1,1,\"10.34.15.70\"\r\n\r\nOK\r\n"
["AT+QIDNSCFG=1,\"8.8.8.8\",\"8.8.4.4\"\­r\n"
] "\r\nOK\r"
Connected
["AT+QNWINFO\r\n"
New interpreter error: UART_OVERFLOW
] "NFO: \"CAT-NB1\",\"53001\",\"LTE BAND 28\",9554\r\n\r\nOK\r\n"

Excellent news, I have loaded the latest hex and my app is running. The only thing I am noticing at the moment is that I am getting occasional UART_OVERFLOW errors with serial to the BG96 and so commands are getting corrupted

I needed to figure out how to create a custom build yesterday (for the first time) and noticed it was down also. I needed to remove/add some libs to MDBT42Q.

But what I found is that it is real easy to do these builds, @Gordon has made the process real easy to make the build process work at https://github.com/espruino/Espruino/blo­b/master/README_Building.md

Took me hour or so to create a custom MDBT42Q build without any prior knowledge - I just used the Ubuntu you can fire up in Windows.

Just for anyone who had not had a go at this.

@Gordon but I am now having an issue where I am getting BLE error 0x6 and BLE error 0x8 with setScan() ? This is the same code I am running fine on nrf52832 hardware. Any thoughts ?

OK it looks like my BG96 got shipped to me still in a factory test mode - so once I got out of that things are working again !

@Gordon I am having problems with the BG96 not accepting some AT commands eg AT+CFUN=1 and AT+CFUN? returns 5 which is not even a documented state. It seems like it is in some non-active state.

I wondered if it is in airplane mode (LTE_WDISABLE pin) - had a quick look but that seemed OK. Did you manage to check if the BG96 was actually working ? I am just not sure if my BG96 has an issue or whether some of the signals from nrf are not in the correct state ?

nrf52840 has so much flash, would be good to have more allocated to Storage region, as that would be good place to store remote software updates

Is the flash_code_start in the correct place at 966656 ?

On the MDBT42 I use the space between flash_binary_end and flash_code_start for the "flash" module for word level logging. But I dont want to end up going up into where the Storage module is putting things ?

@Gordon thanks so much ! I have it up and running. The number of variables needs bumping up for extended RAM, will let you know what else I find

Hi @Gordon just another little check in for an ETA update ?

I see that the nrf52840 has 2x UART, will those both be available ? Will be really useful to be able to debug BLE comms whie one serial port is allocated to the BG96

Thanks

Its ok right now as I also have a rak8212 which I am currently developing on - but having access to more flash/ram will help with new features I need to add. Will the Flash module have access to more space ? We currently use that for our logging data.

@Gordon any update on when you might get to having a look at this build ? Realise you are juggling a lot, just interested in an updated ETA

I have a rak5010 sitting here ready to go !

All good ! My son is enjoying his Bangle.js - turned up 2 days before his birthday which was fantastic

Any update on the timeline for this ? The RAK8212 does not seem to be able to be ordered at the moment

It seemed to be an issue while running bootloader and on saving a second, new copy of the code before deleting the original. It did work if i deleted original code first.

I have not got back to further testing because in the meantime some external changes have meant i need to put a lot more code into the mdbt42. So i am just hoping when i am done that the bootloader plus code save will still work fine. I will let you know when I get there.

A dont reorganize flag may end up being useful

If I can achieve running at boot my bootloader, using Storage to save a new remotely loaded version to flash, then eval from flash then I should be OK as there will be plenty of RAM available.

But if in the above scenario I will run into the issue of the code getting shuffled and so cannot run, then I will have a problem. I don't need to store a second copy of code. If my bootloader detects a new version from remote source, it can delete the current version from Storage (if that helps)

Do you know when you might have a nRF52840 module available ? My project scope has changed and things are starting to get tight inside the MDBT42Q !

So could the compact/rearrange occur during the first eval ? I am not sure if this is the problem, as even if I reboot and try to eval the code later it still fails. So what I was doing originally was

1. Save bootloader from IDE (not using Save on Send so should be all in RAM ?)
   
2. Bootloader runs code ver 1 by eval (This was previously written to storage by bootloader)
   
3. Code ver is running, is notified of software update so reboots to bootloader (E.enableWatchdog(1); while(1);)
   
4. Bootloader receives code v2 via serial port, writes to Storage
   
5. Bootloader eval code v2 but fails due to code errors. Even if I reboot it still fails.
   
   

If I delete code v1 before writing v2 to Storage, it works. Not sure if that shows something I am missing.

I will try your suggestion of eval to RAM as well

OK so I have my MEDBT42 bootloader up and running now. It loads new code in from another module via the serial port, saves to Storage and then eval.

What I started with was keeping a copy of the previous working copy also, but I found then on writing the second, new copy of code on eval the code was corrupt and would not run. The code size is 10.5kB.

I am also saving the bootloader code from the IDE using 'save on send' and I have also observed the bootloader code getting corrupted when saving both copies of main code.

I would not have thought that I am running out of space with my bootloader of 3k and 2x 10.5kb there would be a size issue that would cause the corruption ? Any thoughts ?

What do you mean by your earlier comment of running from flash that 'it will be pretty efficient' ?

What are the downsides to running from flash vs loading to RAM ? (Apart from the deletion issue you pointed out)