This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

code of protocol stack which part of the Protocol I can modify?

Hi there, I need to add more the function based on Bluetooth, and I need the better security of the function. However, I do not want others read flash data freely and I hope only through my certification could the protocol stack jump to the bootloader address or modified the bootloader address. Can you provide the code of protocol stack? Which part of the code could I modified if I add the security certification? By the way, I don’t need to modify the communication part of the Bluetooth. Any help would be greatly appreciated!

  • Hi,

    In order to prevent the flash to be read, you should enable readback protection. You can enable readback protection of the device by writing '00' to the APPROTECT register.

    Our nrfjprog command line tool can for instance do this when programming the firmware:

    nrfjprog -f nrf52 --rbp ALL && nrfjprog --pinreset -f nrf52
    

    Note that the only way to 'reopen/unlock' the device is to issue an ERASEALL command over the SWD programming lines, which first clears your RAM, then erases all your FLASH content.

  • Hi -

    I think you might find that you do NOT want the SoftDevice source code, even if Nordic were to make it available.

    The combination of a specific nRF5x series chip and its accompanying SoftDevice BINARY is pre-qualified at the Bluetooth SIG. This means that when it comes time to do your BT SIG qualification:

    1. You will need to qualify the RF components of the BLE Physical Layer;

    1a) You will likely need US FCC RF certification, and/or European Union CE RF certification, and/or other regulatory RF certifications depending on where your device will be used; (The test house (BQTF) where you have your BT SIG RF qualification performed can probably advise you about regulatory certifications if you are not sure which ones you will need.)

    1. If you have implemented GATT Based services defined by the Bluetooth SIG, you would need to qualify those implementations (except for Generic Access and Generic Attribute which are automatically provided by the SoftDevice and are therefore pre-qualified);

    2. You do not need to qualify GATT based services you have implemented that are not defined by the SIG.

    If for some reason you were not the use the SoftDevice BINARY, you would need to qualify EVERYTHING. (At least L2CAP and above. Maybe some parts of the "controller" between the Physical Layer and L2CAP. I have not used a "controller" that was not pre-qualified, so I'm not sure about that area.)

    There is no avoiding (1) and (1a), you must do those. You can save quite a bit of time and money if you do not need to qualify anything in (2).

    Note that using SIG defined GATT based services based on the reference code in the Nordic SDK will need to be qualified.

    Many of the Bluetooth stack/chip providers -- like Nordic -- provide pre-qualified ("sealed") binary versions of their software for the reasons noted above. When it comes time to qualify, you can simply reference the pre-qualified components and not need to qualify them yourself.

    Cheers!

    --- tom

  • Hi Tom and desongli, I believe that you need to pass regulatory testing if you want to sell the product anyway, not really much help in using "pre-qualified" stack. When it comes to BT SIG certification then yes, certifying only part of the profile/protocol layers is great help, however if you don't want to claim your device as Bluetooth compatible, you can skip even that (e.g. if you use it inside some closed ecosystem you might drop benefit of putting BT SIG logo on the box). However Nordic ha significant IP in the stack and even if they would license it to you (which I doubt) the effort to understand it and modify correctly might be very high. However there are open source BLE/proprietary stacks for nRF52 which you could use if you really want to dig into lower layers but not develop whole stack from scratch (e.g. Zephir and Mynewt projects). However you will then be relying on...

  • ... these projects with support (API, SDK, bug fixing, interoperability...) - unless you are able to take it completely over as in-house development fork.

Related