NRF53833 140s 0x27000

[wxgd]

I compared the S132 and S140 protocol stack files. The S132 file does not occupy the 0x26000 address, while the S140 does occupy the 0x27000 address. However, the application start address set by the IROM1 of the MDK compiler is 0x27000. Is there a problem?

[Einar Thorsrud]

Hi,

The application start address must be as specified in the release notes for the SoftDevice that is used. For S132 that is 0x26000, and this is the address the SoftDevice will jump to. If the application is at a different address, it will not work.

[wxgd]

Thank you for your reply. In the above picture, the file address of the S132 protocol stack does not exceed 0x26000, and the app program address starts from 0x26000. Therefore, S132 and APP were successfully merged using the merge tool. However, the file of the S140 protocol stack exceeds 0x27000, and the program address of the APP starts from 0x27000. Therefore, an error was prompted during the merge and the merge could not be successful. I have some doubts about this and hope to get an answer. thank you

[Einar Thorsrud]

Hi,

Which version of S140 is this? The latest release is 7.3.0, and this ends at 0x26497, well within 0x27000. I suggest you re-download the S140 hex file from here in case the file you are using is corrupt.

[wxgd]

Thank you very much. I solved The problem. The latest release is 7.3.0 is fine. The problematic S140 mentioned above is carried in the SDK(nRF5_SDK_17.1.0_ddde560), and its path is: NRF5_SDK_17. 1.0 _ddde560 - > examples - > ble_peripheral - > ble_app_uart - > hex - > ble_app_uart_pca10100_s140. Hex

[Einar Thorsrud]

Hi,

I am glad to hear it is solved.

PS: The file ble_app_uart_pca10100_s140.hex is allready merged, so this incldue the application as well as the SoftDevice. That is why you see it extend over 0x27000. The SoftDevice hex file itself is also included in the SDK, but that you can find ass140_nrf52_7.2.0_softdevice.hex under components/softdevice/s140/hex/.

[wxgd]

thinks，I got it