I’m not sure if I should be posting this here or in the Silabs forums. But I’ll ask anyway:
Does anyone here has any experience with BGM113? I’ve been trying to adapt the Github class library for BLE112 but it seems there’s still something not being done properly on my side to achieve this.
When I boot the device, I get a group of similar responses and one entirely different at the end. But these don’t match anything I have on the API reference for BGM113:
The device gets booted as soon as I initiate the class library, like this:
bgm113.BGLIB(uart, myReset);
Unfortunately, the responses I get are not the ones I expected for “system_boot” command. If anyone here has had any experience working with this, can you help me out please?
I think so, yes. Its basically the same class library from BLE112, the package/buffer readings I posted were before they were pre-processed (yes I used proper BAUD rates and pointed the proper uart/pins).
The workflow of the library is sort of like this, at least for the very start:
UART port is initiated using the function read_uart() as callback handler.
Inside that function, there are a couple of routines that handle responses, one of them starts at while (_uart_buffer.len() >= 4), meaning that we have at least the minimum amount of bytes to form a header, and from that we can get to know if this is event/command/response.
Within that while cycle, there’s another helper function named parse_packet(), I made sure to print the contents of the buffer before it started the parsing/classification stage, and those contents were the ones I copied here.
The thing is I’m not sure if the boot is really working, or if its being properly initiated. Because I should be getting reads after I execute this line, right?
bgm113.reboot();
Or should I just be getting them by initiating the class library?
constructor(myUart, reset) {
// Configure the imp's hardware
serPort = myUart;
myReset = reset;
_uart_buffer = "";
serPort.setrxfifosize(1000);
serPort.configure(115432, 8, PARITY_NONE, 1, NO_CTSRTS, _HandleRxChar.bindenv(this));
// other constructor code
}
// Internal handler for incoming serial data
function _HandleRxChar() {
local ch = null;
while ((ch = serPort.read()) != -1) {
_uart_buffer += format("%c", ch);
server.log("handleRx for " + _uart_buffer);
}
while (_uart_buffer.len() >= 4) {
// If we have at least enough for the header, then try parsing the buffer
local event = null;
server.log("do your parsing here")
}
}
// -------------------------------------------------------------------------
function reboot() {
if (myReset) {
myReset.configure(DIGITAL_OUT);
myReset.write(0);
imp.wakeup(1, function() {
myReset.write(1);
myReset.configure(DIGITAL_IN);
_uart_buffer = "";
}.bindenv(this))
}
}
}
dev ← hardware.uart0;
res ← hardware.pinN;
myTest ← myBGLIB(dev, res);
myTest.reboot();
After executing the reboot I should be getting a response, truth is I can’t get anything out of this.
a0 - event marker
07 - payload size
0b - endpoint message class
02 - message ID
1f 10 00 00 00 ff 07 - 7 bytes of payload
but, you’re right, they don’t map to anything in the API reference. At least it indicates that your code is talking to the BGM113 and getting sensible (ie. not garbage) back.
I might try changing some of the constant values in the BLE112 library to match what you can extract from the API doc and see what happens, eg BLE_CLASS_ID. SYSTEM -> 01, BLE_MESSAGE_TYPE.COMMAND -> 0x20, BLE_MESSAGE_TYPE. EVENT -> 0xA0
Indeed, that’s the thing. I’ve been trying to get responses from my chip using two approaches:
The BLE112 class library slightly modified for BGM113. This was how I got my responses.
The snippet from my previous comment that is not getting anything back. Not even the “unknown responses” that are outcomes from the 1st approach.
Neither of them give me a workable response. Unfortunately.
Could it be an issue of reset pin and uart configuration? Although its the same for all imp boards regardless of the devices connected to them (in terms of the inputs they recieve).
No, the issue appears to be a change in protocol for the BGM113, as the messages are well-formed.
I would like to see your actual parsing though, to check you are dealing with multiple packets being in the buffer at once - that is not in the code you posted (the “do your parsing here” but).
Well, the thing is that I wrote that second snippet to see if I got a different response and I didn’t.
The first responses I showed you I got them using almost the same functions described in the class library for BLE112.
The parse_packet() function is the one that performs that action. Does that help Hugo?
I don’t upload the code because its too large and I don’t want to flood the post with it (specially if the parts I’m using have not been entirely altered).
parse_packet() function is the one that I’m using. And the issue with it is the following: how do I modify it properly, if I cannot ‘index’ or ‘map’ the responses the Device is sending me?
If it was a change of protocol, it should be documented somewhere. I’ll search on Silabs and ask them in the forums. If I find something I’ll report back here.
a0 - event marker
07 - payload size
0b - endpoint message class
02 - message ID
1f 10 00 00 00 ff 07 - 7 bytes of payload
…the thread notes that these messages don’t get output in the newer firmware versions, and you should update the device’s firmware. Until then you can likely ignore them though.
I’ll ignore them and just process the one I need. In the same post you pasted, there’s reference API link to the 1.0.2 version, which is not far ahead from the 1.0.0 version.