Share the same ATT table between APP and bootloader

[Brian Chang]

Hi,

We had met problem at buttonless DFU with bonded information at Andriod set-top-box.

The problem we saw is we can not know when the ATT table is different at andriod or our device.

The DFU performed service change notification twice but sometime  it is not successful to complete.

Like device already receive the service change confirm but the communication is break or held before service discovery.

Is it possible to share the same ATT tablel (handler value) between bootloader and app without reinitializing all the characteristic manually in bootloader.

Thanks 

Brian Chang

[Hung Bui]

Hi Brian, 

Could you explain a little bit more on the issue " the communication is break or held before service discovery." ? Do you have a sniffer trace ? Do you know what wrong happened ? If the link is not reliable, it's not good for DFU anyway. 

Once option to avoid doing service changed (only do this if you don't have any other option) is to have the DFU service on top of the attribute table in your application. This way when you switch to bootloader, it doesn't matter if you have your services in the bootloader attribute table or not, it still can do DFU update. 

But you need to make sure the DFU master wouldn't do DFU update when you are still in application mode, not bootloader mode. 

[Brian Chang]

Hi Hung Bui,

As bellowing , the failure happen at pkt#22846

512_DFU_Failtosync.btt

Although you would see the ATT notisfication packet is sucessful but no function at set-top-box.

The issue related with Andriod set-top-box GATT condition.

However, your ideal sounds good to always put DFU in the top of ATT table.

My another option is go back to use unbonded DFU but customer have concern due to that is not encryption communication based on LTK.

I would try it 

Thank

BR

Brian

[Hung Bui]

Hi Brian, 

It's quite hard to understand what's in the trace. I assume there are other activity not just the DFU bootloader. 

There is a concern with the solution to put the DFU service on top of the GATT table is that the DFU master (running on the phone/set-top box) wouldn't know if it's the application running or it's the bootloader running. And may try to do DFU update when it's the application, instead of writing to the DFU buttonless service to switch from app to bootloader. But if you have full control of the DFU master side, you can implement a way to check if it's the bootloader or it's the application.