Hello, I am working with nRF5 SDK 17.0.0 and using IAR Embedded Workbench 8.50.1. I am following the Secure DFU bootloader guide as posted here.
On Step B3, I get a build error on my IAR as shown below
Inconsistent wchar_t size
micro_ecc_lib_uECC.c.o(micro_ecc_lib_nrf52.a) has wchar_t size 16 bits
app_error_weak.o and 71 other objects have wchar_t size 32 bits
After searching for the same error, I came across a question asked 3 years ago here. I followed Marco's answer to making the uECC library in ..\sdk\external\micro-ecc\nrf52nf_armgcc\armgcc. After doing so, I moved the generated "micro_ecc_lib_nrf52.a" to ..\sdk\external\micro-ecc\nrf52nf_iar\armgcc to build my project in IAR. Once I did that, I was able to build my project. However, when I tried to load the project onto my board, IAR showed a popup saying it wasn't able to find the source files in micro-ecc directory (i.e. ../micro-ecc\curve-specific.inc, uECC.c, uECC.h). These are files extracted directly from the uECC library download. With the skip buttons on the popup, I can continue programming the board, but DFU doesn't work with the .zip file I created from step C2.
Is my workaround for fixing a build error causing this issue? Is anyone having issue with the uECC library, using IAR?
Thanks in advance,
From your descriptions I am not quite sure if you do exactly the same as what is described in the nRF5 SDK release notes:
Note for IAR 8 users:
(Libraries for IAR 8 require wchar_t to be of size 32 bits while IAR 7 requires 16 bits).
To run a project using IAR 8, follow these intructions:
1. Open the IAR project in IAR 8. The IAR workbench will automatically generate an IAR 8 compatible project file.
2. If the project contains one of the precompiled libraries listed below, replace it
with the IAR 8 compatible alternative (there are no projects targeting nRF51 in this SDK).
3. Save the project.
4. When building the project, you might get the warning: "The header file 'cmsis_iar.h' is obsolete and should not be used. [...]".
- The problem is described in DevZone post: devzone.nordicsemi.com/.../iar-ewarm-8-22-1-complains-about-cmsis_iar-h
The solution is to remove all occurrences of #include <cmsis_iar.h>.
The affected libraries are:
- micro-ecc crypto:
- IAR7: Includes library located in the folder named “…_iar\…”.
- IAR8: Switch to using the library from the folder named “…_armgcc\…”.
- nrf_cc310, nrf_cc310_bl, and nrf_oberon:
- IAR7: Link to a library where “short_wchar” is part of the folder name.
- IAR8: Link to a library without “short_wchar” in the folder name.
- Gazell, NFC Tag, and 802.15.4:
- IAR7: Includes the library where the file name ends with “_iar”.
- IAR8: Switch to using the library with similar file name that ends with “_gcc”.
I do not have IAR 8 here, so I cannot check if just moving the .a file is enough. It may be that you must rather change the include directory (and any other reference to micro-ecc folders) in your IAR project, from the path that includes "_iar\" in its name to the corresponding path that includes "_armgcc\" in its name.
Regarding the DFU issue, in what way does it "not work"? When and how does it fail?
I followed the instruction on using the ..armgcc\. I replaced the .a file (from ..iar\ to ..armgcc\) included in the project instead of moving the file to ..iar\. I still get the popups I mentioned.
I clicked "Skip" and it seems to program the board no problem.
The other part of the issue I mentioned is that it fails on actual DFU using the nRF connect app. Here's the log from the app. The image is 57KB (see log), but it fails with the code NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES.
File Name: app_dfu_package.zip
Size: 57 KB
Soft Device Size: Zero KB
Bootloader Size: Zero KB
[Callback] Central Manager did update state to: Powered ON Connecting to DfuTarg...
centralManager.connect(peripheral, options: nil) [Callback] Central Manager did connect peripheral Connected to DfuTarg Discovering services...
Starting Secure DFU...
Connected to DfuTarg
Secure DFU Service found
Discovering characteristics in DFU Service...
peripheral.discoverCharacteristics(nil, for: FE59) DFU characteristics discovered MTU set to 247 Enabling notifications for 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.setNotifyValue(true, for: 8EC90001-F315-4F60-9FB8-838830DAEA50)
Notifications enabled for 8EC90001-F315-4F60-9FB8-838830DAEA50
Secure DFU Control Point notifications enabled Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x0601, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse) Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50
Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600601000200000000000000000000 Command object info (Max size = 512, Offset = 0, CRC = 00000000) received Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x01018d000000, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse) Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50
Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600101 Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x020000, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse) Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50
Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600201 Packet Receipt Notif disabled (Op Code = 2, Value = 0) Writing to characteristic 8EC90002-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x128a010a4408011240080110341a02cd0120002800300038e8bb03422408031220edf5784de50d899a7fb4f9b65e56975084f4d65781655cbf1239afd520cfe609480052040801120010001a40ff1ee173148ed766334743004c81fcab1114184f0aa7a0190e394cceaf9f71f24801561744bf675c28635a444089d12c809479c649a20f4c7567be2531e22b57, for: 8EC90002-F315-4F60-9FB8-838830DAEA50, type: .withoutResponse) Command object sent (CRC = 2F530D95) Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x03, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse) Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50
Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 6003018d000000950d532f Checksum (Offset = 141, CRC = 2F530D95) received Writing to characteristic 8EC90001-F315-4F60-9FB8-838830DAEA50...
peripheral.writeValue(0x04, for: 8EC90001-F315-4F60-9FB8-838830DAEA50, type: .withResponse) Data written to 8EC90001-F315-4F60-9FB8-838830DAEA50
Notification received from 8EC90001-F315-4F60-9FB8-838830DAEA50, value (0x): 600404 Error 4: Insufficient resources Disconnecting...
[Callback] Central Manager did disconnect peripheral Disconnected
I'm not sure if they are related.
I see. As long as only the .a file is needed both ways should work the same.
The file that you get a popup for seems to be <sdk root folder>/external/micro-ecc/micro-ecc/curve-specific.inc. Provided that micro-ecc was correctly built at that location, the file should have been found by IAR.
I highly recommend building micro-ecc using the batch file (build_all.bat if on windows), found in the <sdk root folder>/external/micro-ecc/ folder. It automatically downloads the micro-ecc source and builds it where the SDK expects it. Please note that the batch file expects version 9-2019-q4-major of the GCC toolchain. If you have a different version installed you will get an error message stating what file to edit in order to use a different toolchain version. (If you run the bat file from cmd.exe then the terminal window will stay open after the bat file has finished, so that you can read any error messages.)
Let's try to sort out the first error (micro-ecc / unfound files) before moving on to the DFU related issues. I suspect that they are related.
I confirmed that all 3 files referenced in the popups are located under <sdk>/external/micro-ecc/micro-ecc/ and the path is included in the project setting. It is weird that IAR can't find the files when it knows where to look. Unless we can determine that this is a non-issue, I'd like to continue to figure out what's going on with the popups.
On another note, I was able to DFU my board with the secure bootloader I built and the default ble_app_buttonless_dfu example. This example is where I started my application from. The size of the DFU package was already ~50KB. Is the additional ~7KB (so ~57KB total) in my application enough to cause the DFU to fail? If so, what's the maximum size of the DFU package where the insufficient resources error will not occur? I am using nRF52810. I am concerned that adding a few drivers (gpio, pwm, i2c) and minimal code was enough to cause DFU to fail.
The popups (when the files are at that location) seems strange, yes. Please note that the path should contain .../micro-ecc/micro-ecc/... That is, a "micro-ecc" folder inside a "micro-ecc" folder. So one can easily get a bit confused.
We have seen some times on Windows that paths containing "../" for navigating "backwards" trough the folder hierarchy leads to paths that are too long. (Because that original path with all the ".." still inside have a longer path length than normal - it has added parts of "navigating into a directory, then back again".) This may lead to files not being found. From what I recall, IDEs then typically report back "invalid path" or similar, but it varies.
Regarding the DFU issue, the nRF52810 has 192 kB of flash. To figure out the amount of flash available to the application, subtract the size of the SoftDevice, bootloader, bootloader settings page (4 kB), mbr params page (4 kB), and any application specific data. See also Memory layout.
There are two flash usage patterns for application DFU: Single bank DFU, and dual bank DFU. For the former, the existing application is erased and the new application is downloaded in place. For the latter, the new application is downloaded in the remaining flash space and checked before replacing the old application. That means for dual bank DFU you need enough flash for holding both the old and the new application.
Please note that the size of the DFU zip package and the size of the application hex file are both different from the size that the application will use in flash. As a rough rule of thumb I would say the final application size would typically be around 1/3 of the corresponding hex file size. The IDE or compiler should report exact application size when you build it.