System command event mismatch between 1.1.0 FW and CM0+ FW.

[Hedley]

I am facing a challenge with the System event response codes. Digging into the FW I find the FW is looking for the status in the wrong part of CPU2's SystemCmdBuffer. It seems CPU2 respects the 8 byte header, whereas FW (with comments) says the evtserial starts immediately (and is coded so) (i.e. where the header would be). As a test, I FF'd out the header and the resultant evtcodes are all FF's indicating the FW is indeed looking into the header for status vs the actual packet return. As another test, I intentionally messed up SHCI_C2_BLE_Init to produce and illegal config. Indeed, the status, at the correct spot, changed from 0 to 0x48 (where is that code in a .h btw?).

tnx

Hedley

Here is the detail:

First, CPU2's revision info:

 hci_read_local_version_information(&HCI_Version,

 9

                       &HCI_Revision,

 36

                       &LMP_PAL_Version,

9

                       &Manufacturer_Name,

48

                       &LMP_PAL_Subversion);

34

The first System command sent:

SHCI_CmdStatus_t SHCI_C2_BLE_Init( SHCI_C2_Ble_Init_Cmd_Packet_t *pCmdPacket )

...

 return (SHCI_CmdStatus_t)(((TL_CcEvt_t*)(p_rsp->evtserial.evt.payload))->payload[0]);

A normal return:

Here is where I think status should be:

0x200301ac:   0x00000000   0x00000000   0x01040e11   0x0000fc66

0x200301bc:   0x00000000   0x00080044   0x01080540   0x009c793a

Intentional erroneous BLE setup:

0x200301ac:   0x00000000   0x00000000   0x01040e11   0x0048fc66

0x200301bc:   0x00000000   0x00000000   0x01000540   0x009c793a

Now we test the FW. Lets set the header to FF's

(gdb) set *(int *)0x200301ac=0xffffffff

(gdb) set *(int *)0x200301b0=0xffffffff

(gdb) x/32x 0x200301ac

0x200301ac <SystemCmdBuffer>:   0xffffffff  0xffffffff   0x00000000   0x00000000

0x200301bc <SystemCmdBuffer+16>: 0xx00000000  0x00000000   0x00000000   0x00000000

Good status back but... look at where rsp is looking...

135    memcpy( &(p_rsp->evtserial), pCmdBuffer, ((TL_EvtSerial_t*)pCmdBuffer)->evt.plen + TL_EVT_HDR_SIZE );

(gdb) x/32x 0x200301ac

0x200301ac <SystemCmdBuffer>:  0xffffffff   0xffffffff   0x01040e11   0x0000fc66

0x200301bc <SystemCmdBuffer+16>:    0x00000000   0x00080044   0x01080540   0x009c793a

0x200301cc <SystemCmdBuffer+32>:    0x010001f4   0xffffffff   0x00010148   0x00000000

0x200301dc <SystemCmdBuffer+48>:    0x00000000   0x00000000   0x00000000   0x00000000

0x200301ec <SystemCmdBuffer+64>:    0x00000000   0x00000000   0x00000000   0x00000000

0x200301fc <SystemCmdBuffer+80>:    0x00000000   0x00000000   0x00000000   0x00000000

0x2003020c <SystemCmdBuffer+96>:    0x00000000   0x00000000   0x00000000   0x00000000

0x2003021c <SystemCmdBuffer+112>:    0x00000000   0x00000000   0x00000000   0x00000000

(gdb) n

140   }

(gdb) p p_rsp

$1 = (TL_EvtPacket_t *) 0x2002fec0

(gdb) p p_rsp[0]

$2 = {header = {next = 0x2002ff00, prev = 0x8003b71 <hci_user_evt_proc>}, evtserial = {type = 255 '\377',

  evt = {evtcode = 255 '\377', plen = 255 '\377', payload = "\377"}}}

[Christophe Arnal]

Hello,

The SHCI_C2_BLE_Init() command can return only two status:

0x00 : successful

0x48: error

The only reason to return an error is when the BLE stack configuration provided by the application does not fit the memory budget available on the CPU2.

You need to decrease the BLE Stack configuration ( number of services, characteristics, etc...) as there is no way to increase the memory budget available on the CPU2.

Regarding the system command response packet format, I am a bit puzzled. According to the version read from the command, It looks like you are holding a CPU2 firmware which is older that the first one that has been officially released.

Before releasing the product, the system command response packet was following the general rules applied to all buffers and the first two 32bits were left free to allow chaining the packet accross layers ( avoiding making copy).

A specification change was required to ensure compatibility with other mechanisms and the first two 32bits are now used to store the response data.

As long as you seems to have an older version, I would recommend to switch to an official one if this is possible.

Given the fact the device seems to not include a released CPU2 firmware, I am not sure you will be able to upgrade it but it is worth trying.

Regards

[Hedley]

Thanks Christophe.

All is good now. I reflashed first the FUS (needed step 5), then the 1.1.0 ble_stack. Now I get HCI_Revision=40 and I do see the command complete event overlaid where the header once used to be.

This chip was prob one of the first blister pack nucleo boards out of Mouser. I am flashing/working with the dongle curr but I am sure the wb55 on the nucleo board is also old.

Hedley