pelioniot / mbed-os-example-pelion-psoc64 Goto Github PK

Describe the bug
After succesfully completing the steps described in the README up to 7 in Building and running the example I get the following error when trying to build:

Compile [ 10.1%]: cborencoder_close_container_checked.c
Compile [ 10.1%]: SimpleM2MResource.cpp
Compile [ 10.2%]: EstClient.cpp
Compile [ 10.3%]: cborencoder.c
Compile [ 10.3%]: UpdateClient.cpp
[Error] arm_uc_config.h@103,2: "Missing APPLICATION_ADDR definition. Check configuration for bootloader binary."
[ERROR] In file included from ./mbed-cloud-client/source/UpdateClient.cpp:40:
In file included from ./mbed-cloud-client/update-client-hub/modules/lwm2m-mbed/update-client-lwm2m/lwm2m-source.h:22:
./mbed-cloud-client/update-client-hub/modules/common/update-client-common/arm_uc_config.h:103:2: error: "Missing APPLICATION_ADDR definition. Check configuration for bootloader binary."
#error "Missing APPLICATION_ADDR definition. Check configuration for bootloader binary."
^
1 error generated.

To Reproduce
see above

Expected behavior
Successful build.

Logs
see above

Host system (please complete the following information):

• OS: Ubunu 20.04
• Mbed Studio 1.2.1

Device information:

• Device: CY8CKIT-064B0S2-4343W

In "Updating firmware" instruction 1. the user is told to edit the file "cytfm_pelion_policy.json" but is not told where to locate said file (TARGET_CYTFM_064B0S2_4343W/policy/cytfm_pelion_policy.json)

Describe the bug

If the platform.stdio-buffered-serial feature is enabled in mbed_app.json, then the system will typically hang some indeterminate time after the Pelion Client is initialized.

"platform.stdio-buffered-serial"            : true,

Normally, enabling buffered serial can result in better stability. But in this case, it causes either the system or just the serial output to crash.

By default we have turned off Buffered Serial until this issue can be resolved. At that point it should be re-enabled.

Things I've investigated

• I see the issue regardless of if ENABLE_CY_FACTORY_FLOW is enabled or not.

• I also see it regardless if EXPERIMENTAL_API which I think enables PSA APIs for crypto operations.

• Also doubling rtos.thread-user-stack-size doesn't seem to make a difference.

• I created a simpler example application which has 4 threads that each print lots of data to the serial port at different intervals, and one thread that downloads data from a socket. I never see the issue. However, it is easy to reproduce with the cloud client example application.

• I haven't been able to get the debugger to connect to debug it further.

To Reproduce
Steps to reproduce the behavior:

1. Set "platform.stdio-buffered-serial" to true
2. Follow the other steps in the readme to build and run the application.
3. See error

Expected behavior
It should not hang.

Logs
none

Host system (please complete the following information):

• OS: [Windows x.y, Ubuntu x.y, ...]
• Compiler: Arm Compiler
• Compiler version: 6.14
• Mbed CLI version (if used): Tested with Mbed Studio

Device information:

• Device: CY8CKIT-064B0S2-4343W (using build target CYTFM_064B0S2_4343W)
• OS: Mbed 6.2.1
• Client version: 4.6.0
• Other SW: n/a

Additional context
none

Describe the bug
In the readme file at https://github.com/ARMmbed/mbed-os-example-pelion-armdevsummit/blob/armdevsummit/TARGET_CYTFM_064B0S2_4343W/README.md

In Section:
Generating and provisioning Device Management credentials

Step 5

I don't think these steps are needed. Or at least the step about creating keys is not needed. Because the next step uses 'existing keys'. Therefore the second set of keys are not really used. I think the readme is also wrong in this case. The first keys are important, and should not be deleted. The second keys are not necessary.

We need to confirm this and fix the readme as soon as possible.

Describe the bug
In the readme for CYTFM_... at
https://github.com/ARMmbed/mbed-os-example-pelion-armdevsummit/blob/armdevsummit/TARGET_CYTFM_064B0S2_4343W/README.md#building-and-running-the-example

It says that Mac OS is case-insensitive and requires applying a patch to the application. this is not true. It shouldn't be required because Mac is case-sensitive. However, I guess it does't hurt.

With the new instructions for Mbed Studio, the paths should be changed to /ARM/ and not /GCC_ARM

example, in this command
python inthex2bin.py BUILD/CYTFM_064B0S2_4343W/GCC_ARM/mbed-os-example-pelion_upgrade.hex

it should be
python inthex2bin.py BUILD/CYTFM_064B0S2_4343W/ARMC6/mbed-os-example-pelion-armdevsummit_upgrade.hex

(also need to change references to the example application name, which is now mbed-os-example-pelion-armdevsummit)

When trying to perform the device update I have to enter the device ID. It was not clear what this ID should be, I tried to use the serial number I used earlier on in the process but this lead to a stuck update campaign saying it had an invalid UUID.

The instructions should be updated to explain you can get this ID from: https://portal.mbedcloud.com/devices/list in the Device ID column

1. Error in Readme

   LED should be blinking to get into DAPLink mode.

2. Need instructions to reset board to factory state if provisioning failed

At least on MacOS, I was unable to copy from the serial terminal to get the "Device enrollment key", I ended up having to reset the device with the provided command and then keep the board in reset until I opened the serial port in something else (In my case coolterm)

I think having two readme files is confusing. Can we move the CYTFM... readme to the top?