Add support for ADI EV-COG-AD3029LZ platform #5137

dave-wu · 2017-09-19T06:00:42Z

Description

Adding support to the EV-COG-AD3029LZ platform. Re-submitted as a new pull request to replace PR #5097.

Status

Ready.

Migrations

NO

Related PRs

Replacement of PR #5097.

0xc0170 · 2017-09-29T13:50:40Z

@dave-wu I can see that similar things that came up from another target, are in this one as well, can you confirm? in case yes, please update us once they are addressed

0xc0170 · 2017-10-05T08:57:03Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+/* RNG Device memory */
+static uint8_t RngDevMem[ADI_RNG_MEMORY_SIZE];
+
+void trng_init(trng_t *obj)


@RonEld @yanesca Please review. I believe this is similar implementation to the other device being added

@dave-wu Is that correct?

@0xc0170 Please label this with the tls component, so we could track it.
I have same comments as other device being added, once the other device comments will be resolved, and merged here, I will review here as well

0xc0170 · 2017-10-05T08:59:54Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/us_ticker.c

+   	if (largecnt >= 65536u) {
+   		largecnt -= 65536u;
+   	} else
+   		largecnt = 0;


Can you align the codestyle in this file? (https://docs.mbed.com/docs/mbed-os-handbook/en/latest/cont/code_style/)

mbed-ci · 2017-10-11T05:56:04Z

Build : SUCCESS

Build number : 99
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5137/

Triggering tests

/test mbed-os

dave-wu · 2017-10-12T04:10:36Z

Added test results for the platform.
cog3029-20171012.zip

yanesca · 2017-10-18T12:07:43Z

@0xc0170 Could you please add the 'tracking' label to this PR?

0xc0170 · 2017-10-18T12:13:16Z

@dave-wu As soon as the other target is green (approved and all CI are green), I'll review this one as I see those 2 really similar so we dont need to duplicate the review and changes (the requested changes should also be done for this target). Let us know if all has been resolved for this target.

ciarmcom · 2017-10-20T13:45:59Z

ARM Internal Ref: IOTSSL-1833

mazimkhan · 2017-10-31T10:58:13Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+        output[i] = (uint8_t)(nRandomNum & 0xFF);
+
+        // Clear nRandomNum on the stack before exiting
+        nRandomNum = 0;


To avoid compiler optimising this memory scrubbing nRandomNum should be volatile.

mazimkhan · 2017-10-31T12:03:41Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+    adi_rng_EnableBuffering(RNGhDevice, false);
+
+    // Enable the TRNG
+    adi_rng_Enable(RNGhDevice, true);


adi_rng_EnableBuffering and adi_rng_Enable can fail based on definition in adi_rng.h. Wouldn't it be good idea to check status here. Also, initialise memset( (void *)obj, 0, sizeof( trng_t ) ); so that uninitialised object can be checked in other functions using the obj.

@mazimkhan That's a general problem with the interfaces I'd say, since trng_init is not allowed to fail (and there's no xxx_setup function as in other modules). An ugly way to get around this would be to extend

struct trng_s { ADI_RNG_HANDLE RNGhDevice; };

by some flag indicating that something went wrong during initialization, and checking for that in trng_get_bytes.

@hanno-arm But if the adi_xxx functions fail, we should assertr in this case, or something of the sort. I don't think we should continue operation

@RonEld I agree, but the interface doesn't allow to signal the error. I don't know if an assert would be acceptable here and how it would affect overall system operation @0xc0170.

@dave-wu do you agree to error() if init fails ? If yes, please add it as requested above

mazimkhan · 2017-10-31T12:04:41Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+
+void trng_free(trng_t *obj)
+{
+    ADI_RNG_HANDLE RNGhDevice = obj->RNGhDevice;


Would there be a merit in checking is obj is properly initialised.

mazimkhan · 2017-10-31T12:06:12Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+
+int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length)
+{
+    ADI_RNG_HANDLE RNGhDevice = obj->RNGhDevice;


Would there be a merit in checking is obj if properly initialised. It is very hw dependent. Hence up to you. However, it is good to document the behaviour when obj is not valid or if initialisation is not suppose to fail.

mazimkhan · 2017-10-31T12:47:01Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/api/trng_api.c

+    for (i = 0; i < length; i++) {
+        // Loop until the device has data to be read
+        do {
+            result = adi_rng_GetRdyStatus(RNGhDevice, &bRNGRdy);


Should we check adi_rng_GetStuckStatus as well and abort the loop if oscillator is stuck.

Related discussion in #5144. From what I saw, the spec doesn't say anything about whether RNRDY being set entails STUCK being unset, so I'd also prefer to check the STUCK flag here.

adbridge · 2017-10-31T14:55:13Z

@dave-wu Could you please address @mazimkhan review comments?

mazimkhan · 2017-10-31T14:37:13Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/bsp/rng/adi_rng.c

+    *phDevice = (ADI_RNG_HANDLE) NULL;
+
+#ifdef ADI_DEBUG
+    if (nDeviceNum >= NUM_RNG_DEVICES)


Why are these check inside debug flag?

I think these are for internal testing by the driver developers only.

mazimkhan · 2017-10-31T14:39:30Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/bsp/rng/adi_rng.c

+    pDevice->pData->CBFunc  = NULL;
+
+    /* clear any pending interrupts. Both bits are write 1 to clear */
+    pDevice->pRNG->STAT = BITM_RNG_STAT_RNRDY | BITM_RNG_STAT_STUCK;


BITM_RNG_STAT_STUCK is enabled here but not checked in trng_get_bytes.

mazimkhan · 2017-10-31T14:43:10Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/bsp/rng/adi_rng.c

+    ADI_INT_STATUS_ALLOC();
+
+#ifdef ADI_DEBUG
+    if (ADI_RNG_INVALID_HANDLE(pDevice)) {


Why guard these vital checks inside debug flag?

@dave-wu Is this also for internal testing by the drivers developers? Please check, it seems to me that this check is important not only for debug

@RonEld Had another look and I think you are right, these should be enabled as they check for invalid handles and they are the conditions that return the prescribed error codes. I will need to discuss with the driver development guys to get them to fix this in their next release. If you are OK with it I'll leave them for now and add in the fix when the new BSP becomes available.

As long as you are aware of this, and that you will have to make a new release, I'm fine

mazimkhan · 2017-10-31T14:44:11Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/bsp/rng/adi_rng.c

+    ADI_RNG_DEV_TYPE *pDevice = (ADI_RNG_DEV_TYPE*)hDevice;
+    ADI_INT_STATUS_ALLOC();
+
+#ifdef ADI_DEBUG


Why guard these vital checks inside debug flag?

mazimkhan · 2017-10-31T14:56:07Z

targets/TARGET_Analog_Devices/TARGET_ADUCM302X/TARGET_ADUCM3029/bsp/rng/adi_rng.c

+                    nEvent = ADI_RNG_EVENT_STUCK;
+                    candidate &= (uint16_t)~BITM_RNG_STAT_STUCK;
+                } else {
+                    break;


Is it robust to ignore other events silently on an unrecognised event.

This has been discussed in the PR thread for the 4050LZ. The STUCK flag is now checked in the trng_get_bytes to make sure no hardware errors have occurred.

hanno-becker

Thanks for adressing the comments, @dave-wu.

I have reviewed the TRNG driver code from trng_api.c, adi_rng.c and adi_rng.h and that part of the PR looks good to me.

Two comments:

As @mazimkhan mentioned, trng_init calls potentially failing function but dicards their return value. This is a general problem with the trng_xxx interface, though, which other drivers are also suffering from, and I'm ok with leaving it as is.
The functions in question actually never fail because the relevant checks are guarded by a debug-flag. While I share @mazimkhan's question as to whether they aren't enabled unconditionally, it doesn't constitute a problem for this PR because all parameters are hardcoded in trng_init and satisfy the checks.

dave-wu · 2017-11-12T23:40:55Z

@0xc0170 Could you please look at merging this as well? All the changes that I have done for the 4050LZ PR that are relevant to this platform have also been applied for this PR.

0xc0170 · 2017-11-13T09:48:19Z

@0xc0170 Could you please look at merging this as well? All the changes that I have done for the 4050LZ PR that are relevant to this platform have also been applied for this PR.

Yes, we will review this , thanks for the update

dave-wu · 2017-11-13T23:49:46Z

@0xc0170 Just did a commit to resolve the conflicts with the master.

0xc0170 · 2017-11-14T09:59:57Z

@dave-wu Still a conflict here. You can rebase to resolve conflicts (so each commit would be on top of the latest master).

hanno-becker · 2017-11-14T10:01:22Z

Please note that this is pending another review from @Patater or @mazimkhan.

dave-wu · 2017-11-14T11:29:09Z

@0xc0170 This PR is on the master branch of my copy of mbed-os, not sure how I can rebase that. Is there an easier way to resolve these conflicts? From the looks of it the conflicts are minimal and straight forward to resolve, so can it be easily resolved in the merge instead of doing rebasing?

P.S. I just made another update to target.json, to base on the latest target.json from the master branch.

dave-wu · 2017-11-15T11:40:51Z

@0xc0170 I did answer @RonEld's comments regarding adi_rng.c.
@RonEld Please let me know.

RonEld

I approve this, with the condition that a new release is mandatory, but the issue is not blocking, at the moment

RonEld · 2017-11-15T12:01:56Z

@dave-wu In addition, you should open a github issue so the handle checking won't be missed

dave-wu · 2017-11-15T12:03:24Z

@RonEld Will do. Thanks.

0xc0170 · 2017-11-15T13:03:58Z

/morph build

mbed-ci · 2017-11-15T13:52:17Z

Build : FAILURE

Build number : 525
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5137/

0xc0170 · 2017-11-15T13:57:40Z

@dave-wu Can you please look at the failure ? It reports that SystemCoreClock is undeclared (should be defined in system__ header file and externally linked).

dave-wu · 2017-11-15T15:07:11Z

@0xc0170 SystemCoreClock is declared in system_aducm3029.c. From the build log it seems this file was not copied by the build script for some reason. Does the build exclude the startup files?

theotherjimmy · 2017-11-15T21:09:49Z

targets/targets.json

+        "core": "Cortex-M3",
+        "supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
+        "macros": ["__ADUCM3029__", "EV_COG_AD3029LZ"],
+        "extra_labels": ["Analog_Devices", "ADUCM302X", "ADUCM3029", "EV_COG_AD3029LZ", "FLASH_CMSIS_ALGO"],


"EV_COG_AD3029LZ",

is not needed here, as it matches the name of the target exactly. The target is already a label so adding it again, with extra_labels, is redundant.

theotherjimmy · 2017-11-15T21:15:42Z

@studavekar I can't reproduce the build errors locally. I'm going to give it another go. If it fails again, could you look into it?
/morph build

mbed-ci · 2017-11-15T21:52:13Z

Build : FAILURE

Build number : 528
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5137/

theotherjimmy · 2017-11-15T22:05:47Z

It looks like #5342 was merged to master since you last rebased. Merging with the current master prevents this PR from building. I was able to reproduce the issue after updating my master branch.

dave-wu · 2017-11-16T10:54:43Z

@theotherjimmy Any resolution on this build issue?

0xc0170 · 2017-11-16T11:27:32Z

@dave-wu You should be able to reproduce the issue if you merge with master your branch or rather rebase to get the changes from master (do it on another branch so won't change this one. I can see you are working on your master).

Looking at the error. the file os_systick.c cant find the definition for SystemCoreClock . As it includes cmsis.h this is how it pulls it , I would check the include paths are correct and the definition can be seen via cmsis.h header file.

dave-wu · 2017-11-16T13:34:02Z

@0xc0170 Just added extern SystemCoreClock to system_aducm3029.h which gets included in cmsis.h and it builds now. Could you please retest?

0xc0170 · 2017-11-16T13:57:13Z

/morph build

mbed-ci · 2017-11-16T14:32:23Z

Build : SUCCESS

Build number : 533
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5137/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2017-11-16T15:16:39Z

Exporter Build : SUCCESS

Build number : 147
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5137/

mbed-ci · 2017-11-16T15:41:54Z

Test : SUCCESS

Build number : 342
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5137/342

0xc0170 added needs: review scope: new-target labels Sep 19, 2017

dave-wu mentioned this pull request Sep 19, 2017

Adi cog candidate #5097

Closed

dave-wu force-pushed the master branch from 85fcad5 to df3a93f Compare September 20, 2017 00:54

0xc0170 reviewed Oct 5, 2017

View reviewed changes

0xc0170 added the component: security label Oct 10, 2017

0xc0170 added the tracking label Oct 18, 2017

ciarmcom added the mirrored label Oct 20, 2017

mazimkhan suggested changes Oct 31, 2017

View reviewed changes

mazimkhan reviewed Oct 31, 2017

View reviewed changes

adbridge added needs: work and removed needs: review labels Oct 31, 2017

mazimkhan reviewed Oct 31, 2017

View reviewed changes

hanno-becker approved these changes Nov 2, 2017

View reviewed changes

0xc0170 added needs: review and removed needs: work labels Nov 13, 2017

RonEld approved these changes Nov 15, 2017

View reviewed changes

Cleaned up some formatting issues.

4016742

0xc0170 removed the needs: work label Nov 15, 2017

theotherjimmy reviewed Nov 15, 2017

View reviewed changes

Added SystemCoreClock as an extern.

45aa213

0xc0170 added the release-version: 5.6.5 label Nov 16, 2017

0xc0170 approved these changes Nov 17, 2017

View reviewed changes

0xc0170 changed the title ~~Added support for ADI EV-COG-AD3029LZ platform.~~ Add support for ADI EV-COG-AD3029LZ platform Nov 17, 2017

0xc0170 merged commit b025ea1 into ARMmbed:master Nov 17, 2017

This was referenced Nov 21, 2017

Analog_Devices: Add armc6 features #5540

Closed

Add ARMC6 feature to EV_COG_AD4050LZ and EV_COG_AD3029LZ #5541

Closed

li-ho mentioned this pull request Nov 30, 2017

ADI: Add ARMC6 compatible code #5627

Merged

ciarmcom added the closed_in_jira label Dec 1, 2017

Add support for ADI EV-COG-AD3029LZ platform #5137

Add support for ADI EV-COG-AD3029LZ platform #5137

Conversation

dave-wu commented Sep 19, 2017 • edited by 0xc0170

Description

Status

Migrations

Related PRs

0xc0170 commented Sep 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbed-ci commented Oct 11, 2017

Triggering tests

dave-wu commented Oct 12, 2017

yanesca commented Oct 18, 2017

0xc0170 commented Oct 18, 2017 • edited

ciarmcom commented Oct 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mazimkhan Oct 31, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adbridge commented Oct 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RonEld Nov 15, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanno-becker left a comment

Choose a reason for hiding this comment

dave-wu commented Nov 12, 2017

0xc0170 commented Nov 13, 2017

dave-wu commented Nov 13, 2017

0xc0170 commented Nov 14, 2017

hanno-becker commented Nov 14, 2017

dave-wu commented Nov 14, 2017 • edited

dave-wu commented Nov 15, 2017

RonEld left a comment

Choose a reason for hiding this comment

RonEld commented Nov 15, 2017

dave-wu commented Nov 15, 2017

0xc0170 commented Nov 15, 2017

mbed-ci commented Nov 15, 2017

0xc0170 commented Nov 15, 2017 • edited

dave-wu commented Nov 15, 2017

Choose a reason for hiding this comment

theotherjimmy commented Nov 15, 2017

mbed-ci commented Nov 15, 2017

theotherjimmy commented Nov 15, 2017

dave-wu commented Nov 16, 2017

0xc0170 commented Nov 16, 2017

dave-wu commented Nov 16, 2017

0xc0170 commented Nov 16, 2017

mbed-ci commented Nov 16, 2017

Triggering tests

mbed-ci commented Nov 16, 2017

mbed-ci commented Nov 16, 2017

dave-wu commented Sep 19, 2017 •

edited by 0xc0170

0xc0170 commented Oct 18, 2017 •

edited

mazimkhan Oct 31, 2017 •

edited

RonEld Nov 15, 2017 •

edited

dave-wu commented Nov 14, 2017 •

edited

0xc0170 commented Nov 15, 2017 •

edited