Add RDA's new target UNO_81C #6508

RdaZhongyao · 2018-03-29T09:19:19Z

Description

New target UNO_81C from RDA Microelectronics.

Pull request type

[ ] Fix
[ ] Refactor
[x] New target
[ ] Feature
[ ] Breaking change

greentea logs are attached below:
c6cd6ef_GT_Log_ARMCC.txt
c6cd6ef_GT_Log_GCC.txt
c6cd6ef_GT_Log_IAR.txt

cmonr · 2018-04-03T02:34:47Z

@RdaZhongyao, could you share the test results for all three compilers with this new target?

cmonr · 2018-04-03T02:35:26Z

Also, please take a look at the failing Travis CI results.

ashok-rao

Some comments added..thanks!

ashok-rao · 2018-04-03T08:40:11Z

platform/mbed_lib.json

@@ -42,6 +42,9 @@
        },
        "EFR32": {
            "stdio-baud-rate": 115200
+        },
+        "UNO_91H": {
+            "stdio-baud-rate": 115200


Why default baud = 115200? Mbed OS default = 9600..

Baud 9600 is slow while testing, either 9600 or 115200 can be default.
Actually, the chip supports 1200 ~ 921600.

we are aware that it is slow, thus an app can overwrite, just that it has been defined as 9600 is default. The other 2 families are here because there are hw limitations and can do only 115200.

ashok-rao · 2018-04-03T08:40:27Z

targets/TARGET_RDA/TARGET_UNO_91H/PinNames.h

+
+    LED1    = GPIO_PIN21,
+    LED2    = GPIO_PIN1,
+


no user buttons or other analog input on the target?

The board contains 6 buttons, using only 1 ADC pin.

It would be useful to have atleast 1 button defined for user.

ashok-rao · 2018-04-03T08:41:26Z

targets/TARGET_RDA/TARGET_UNO_91H/PinNames.h

+
+    I2C_SCL = PC_0,
+    I2C_SDA = PC_1,
+


no SPI peripheral brought out?

1 SPI master supported, Arduino like pin layout provided on the board (D10~D13).

In that case, you may want to define the Arduino pin maps also here (which I see is already done)..thanks!

ashok-rao · 2018-04-03T08:53:38Z

targets/targets.json

+        "detect_code": ["8002"]
+    },
+    "UNO_91H": {
+        "inherits": ["UNO_81C"],


This should inherit from "RDA5981X" (parent target) rather than another derived target (UNO_81C).. this is required for Mbed 2 to build from online compiler.. I can see release_version above needs Mbed 2 as well..

RDA5981X chip series contain 81C/81AM/81A, they share the original name "91H". especially, 91H is an alias for 81C.
UNO_91H will be removed to meet the mbed 2 rules.

0xc0170 · 2018-04-03T09:48:17Z

@hanno-arm @mazimkhan There's TRNG implementation , please review

ciarmcom · 2018-04-03T11:50:25Z

ARM Internal Ref: IOTSSL-2205

hanno-becker · 2018-04-04T12:16:30Z

targets/TARGET_RDA/TARGET_UNO_91H/trng_api.c

+    if(0U == obj->byte_idx) {
+        int n;
+        /* Delay for PRNG data ready */
+        for(n = 0; n < 4096; n++);


This might be optimized away by the compiler, and even if it's not, it's not a reliable way to enforce a delay. Please clarify and quantify the need for a delay here and use an appropriate waiting mechanism.

The data rate generated by TRNG analog module is 1M(bps), so the TRNG_CTRL outputs 32-bit data in 1/32M(bps). There is no complete-flag or Interrupt mechanism, the delay should be implemented by software. How about using us_ticker_read()? @hanno-arm

@RdaZhongyao It is surprising to hear that the TRNG does neither support notification via interrupt nor via complete flag. If the only information available is the output rate, a static and reliable wait together with a check that the TRNG is in ordinary operation (if there's a register for that) seems to be the best option that remains. @mazimkhan @0xc0170 Ping.

us_ticker_read() would be better in this case than just a sw loop

hanno-becker · 2018-04-04T12:19:54Z

@RdaZhongyao @0xc0170 @cmonr Could one of you provide access to a technical reference manual?

cmonr · 2018-04-04T15:12:43Z

@hanno-arm I wasn't able to find/source any documentation for these boards.

I suspect it will have to come from @RdaZhongyao or maybe @ashok-rao

ashok-rao · 2018-04-04T16:17:11Z

I don't have any docs I'm afraid..

RdaZhongyao · 2018-04-08T03:23:22Z

@hanno-arm There's no public technical reference manual for now. If interested in the TRNG module, I can apply for it.

hanno-becker · 2018-04-09T14:28:04Z

@RdaZhongyao If possible, that would be very helpful - otherwise we can't review the TRNG code to a sufficient degree of confidence.

hanno-becker

The waiting mechanism implemented in trng_get_byte in trng_api.c is not reliable and needs to be changed. Discussion is ongoing what the available and appropriate alternatives are. Apart from that, I couldn't perform a thorough review because the technical reference for the board in question is missing.

hanno-becker · 2018-04-10T16:07:36Z

Thanks @RdaZhongyao for updating the waiting mechanism! Can you provide the reference manual for the TRNG?

0xc0170

libhal - what version of toolchains were used to generate it? would it be good if that is documented in the Readme there in the folder where they are placed?

0xc0170 · 2018-04-16T13:16:38Z

targets/TARGET_RDA/TARGET_UNO_91H/analogin_api.c

+static unsigned char adc1_gp = 0U;
+static int adc_inited_cnt = 0;
+
+void analogin_init(analogin_t *obj, PinName pin) {


{ new line for function body, please correct in all HAL implementation files like this one

0xc0170 · 2018-04-16T13:16:55Z

targets/TARGET_RDA/TARGET_UNO_91H/analogin_api.c

+void analogin_free(analogin_t *obj) {
+    unsigned char gp = 6U;
+    adc_inited_cnt--;
+    if(0 == adc_inited_cnt) {


if () space between

0xc0170 · 2018-04-16T13:18:00Z

targets/TARGET_RDA/TARGET_UNO_91H/us_ticker.c

+    if (!us_ticker_inited)
+        us_ticker_init();
+
+#if DEVICE_SLEEP


How is this related to ticker? Shall a comment be placed here?

0xc0170 · 2018-04-16T13:19:03Z

targets/TARGET_RDA/TARGET_UNO_91H/serial_api.c

+    UARTName uart_cts = (UARTName)pinmap_find_peripheral(txflow, PinMap_UART_CTS);
+
+    if ((UART_1 == uart_cts) && (NULL != uart1))
+    {


{ same line as the condition

0xc0170 · 2018-04-16T13:19:51Z

targets/TARGET_RDA/TARGET_UNO_91H/serial_api.c

+#endif
+}
+
+void uart0_irq() {uart_irq((RDA_UART0->IIR & 0x0FUL), 0, (RDA_UART_TypeDef*)RDA_UART0);}


separate lines for the function call

void uart0.. { uart_irq(); }

0xc0170 · 2018-04-16T13:20:46Z

targets/TARGET_RDA/TARGET_UNO_91H/serial_api.c

+            (irq_handler[index])(uart_data[index].serial_irq_id, irq_type);
+
+#if DEVICE_SLEEP
+    if((0 == index) && (RxIrq == irq_type) && (uart_data[index].rx_irq_set_api) && (NULL != uart_wakeup_handler)) {


similar question to ticker, it might related to the driver used, that if sleep functionality is implemented, IRQ handler needs to to something ?

0xc0170 · 2018-04-16T13:22:04Z

targets/TARGET_RDA/TARGET_UNO_91H/lp_ticker.c

+    uint32_t delay_ticks = SystemCoreClock / LP_TIMER_CLOCK_SOURCE / 5;
+    if (delta <= 0) {
+        // This event was in the past:
+        lp_ticker_irq_handler();


please remove this, its handled in the above. This also would lead to stack overflow (we have fire interrupt function to fire it asap)

README file was added.

cmonr · 2018-04-27T01:53:11Z

Going to get morph running.

/morph build

mbed-ci · 2018-04-27T02:33:32Z

Build : FAILURE

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

0xc0170 · 2018-04-27T07:05:37Z

@RdaZhongyao Please review the build logs for failures (this target fails to build for all 3 toolchains)

…target

cmonr · 2018-05-07T16:14:57Z

/morph build

mbed-ci · 2018-05-07T18:42:50Z

Build : SUCCESS

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

Triggering tests

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

mbed-ci · 2018-05-08T01:24:47Z

Test : SUCCESS

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

mbed-ci · 2018-05-08T02:09:09Z

Exporter Build : SUCCESS

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

0xc0170 · 2018-05-08T09:39:58Z

targets/TARGET_RDA/TARGET_UNO_91H/lib/README.md

@@ -0,0 +1,4 @@
+libhal files in the subfolders are generated with toolchains:
+* **Arm Compiler 5** - version 5.06u1
+* **GNU Arm Embedded** - version 4.9.3


Can this be updated to gcc 6 ?

What actually is in this archive? SDK drivers?

Archive is mainly about sleep strategy.

0xc0170 · 2018-05-08T09:40:28Z

targets/TARGET_RDA/TARGET_UNO_91H/lp_ticker.c

+
+int lp_ticker_soft_int_flag = 0;
+
+#if DEVICE_SLEEP


From reading the code it is not clear why device sleep has impact on lp ticker or us ticker (I can see ifdef in the implementation)

If enter sleep mode, we will change clk source, so need conversion to calibration

0xc0170 · 2018-05-08T09:40:45Z

targets/TARGET_RDA/TARGET_UNO_91H/lp_ticker.c

+        lp_ticker_init();
+
+    /* Get timestamp from us_ticker */
+    return us_ticker_read();


lp ticker read = us ticker read?

yes,we only have one timestamp, lp ticker and us ticker share it.

0xc0170 · 2018-05-08T09:42:28Z

targets/TARGET_RDA/TARGET_UNO_91H/sleep.c

+    mbed_interface_disconnect();
+#endif
+
+#if defined(RDA_SLEEP_MODE)


what does RDA_SLEEP_MODE mean - is it defined? Where is it documented?

User can decide whether to allow sleep and set wakeup source (GPIO or UART) if RDA_SLEEP_MODE defined. We don't have public technical reference manual for now.

cmonr · 2018-05-14T04:37:37Z

@RdaZhongyao ?

cmonr · 2018-05-21T16:27:38Z

Closing this PR due to lack of activity. Feel free to reopen once updates are available.

Ronny-Liu · 2018-06-19T02:56:55Z

Let's reopen this PR. Our partner had some changes and new engineers are assigned to this.

mbed-ci · 2018-06-19T13:33:40Z

Build : FAILURE

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

cmonr · 2018-06-19T13:40:42Z

@studavekar ^^^ Phantom build?

mbed-ci · 2018-06-19T15:23:04Z

Exporter Build : FAILURE

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

cmonr · 2018-06-19T18:36:08Z

@studavekar ^^^ Phantom build.

Ronny-Liu · 2018-06-22T11:59:02Z

@cmonr Is that technically possible to allow kyliuxing edit directly on web UI? Since the original PR owner has left RDA and kyliuxing is now picking this up. If it is not possible then we should close this PR and create a new one.

cmonr · 2018-06-22T21:25:55Z

@Ronny-Liu If it's not already possible, I would simply suggest closing this and opening a new PR. Just be sure to mention a link to the new PR here for tracking purposes.

cmonr · 2018-06-28T15:18:19Z

@RdaZhongyao Is work still being done on this PR, or was it migrated to #7309?

kyliuxing · 2018-06-29T02:30:13Z

@cmonr RdaZhongyao has left RDA, so please migrate it to #7309.

RdaZhongyao force-pushed the master branch from 9eb7a6e to 854f3a9 Compare March 31, 2018 11:28

cmonr requested a review from ashok-rao April 3, 2018 02:33

cmonr added the scope: new-target label Apr 3, 2018

cmonr added the needs: work label Apr 3, 2018

cmonr requested a review from 0xc0170 April 3, 2018 02:35

ashok-rao reviewed Apr 3, 2018

View reviewed changes

0xc0170 requested review from mazimkhan and hanno-becker April 3, 2018 09:47

0xc0170 added tracking component: security labels Apr 3, 2018

ciarmcom added the mirrored label Apr 3, 2018

RdaZhongyao force-pushed the master branch from 854f3a9 to 1a0e51a Compare April 4, 2018 04:18

RdaZhongyao changed the title ~~Add RDA's new target UNO_91H/UNO_81C~~ Add RDA's new target UNO_81C Apr 4, 2018

hanno-becker reviewed Apr 4, 2018

View reviewed changes

RdaZhongyao force-pushed the master branch from 1a0e51a to d2d7aa4 Compare April 8, 2018 12:32

hanno-becker suggested changes Apr 9, 2018

View reviewed changes

0xc0170 added needs: review and removed needs: work labels Apr 11, 2018

0xc0170 previously requested changes Apr 16, 2018

View reviewed changes

0xc0170 added the needs: work label Apr 17, 2018

RdaZhongyao force-pushed the master branch from 1804cb0 to c6cd6ef Compare April 19, 2018 02:42

remove MBED_HEAP_STATS_ENABLED macro, treat RDA5981X as a non-public …

878021d

…target

0xc0170 reviewed May 8, 2018

View reviewed changes

0xc0170 requested changes May 8, 2018

View reviewed changes

cmonr closed this May 21, 2018

ciarmcom added the closed_in_jira label May 21, 2018

cmonr reopened this Jun 19, 2018

This was referenced Jun 23, 2018

Add RDA's new target UNO_81C #7305

Closed

New target UNO_91H from RDA Microelectronics. #7309

Merged

0xc0170 closed this Jun 29, 2018

0xc0170 removed the needs: work label Jun 29, 2018

Add RDA's new target UNO_81C #6508

Add RDA's new target UNO_81C #6508

Uh oh!

Conversation

RdaZhongyao commented Mar 29, 2018 • edited by adbridge Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Pull request type

Uh oh!

cmonr commented Apr 3, 2018

Uh oh!

cmonr commented Apr 3, 2018

Uh oh!

ashok-rao left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ashok-rao Apr 4, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Apr 3, 2018

Uh oh!

ciarmcom commented Apr 3, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanno-becker commented Apr 4, 2018

Uh oh!

cmonr commented Apr 4, 2018

Uh oh!

ashok-rao commented Apr 4, 2018

Uh oh!

RdaZhongyao commented Apr 8, 2018

Uh oh!

hanno-becker commented Apr 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hanno-becker left a comment

Choose a reason for hiding this comment

Uh oh!

hanno-becker commented Apr 10, 2018

Uh oh!

0xc0170 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

RdaZhongyao commented Mar 29, 2018 •

edited by adbridge

Loading

ashok-rao Apr 4, 2018 •

edited

Loading

hanno-becker commented Apr 9, 2018 •

edited

Loading