Add support for ADI EV-COG-AD4050LZ platform. #5144

dave-wu · 2017-09-20T04:44:16Z

Notes:

Pull requests will not be accepted until the submitter has agreed to the contributer agreement.
This is just a template, so feel free to use/remove the unnecessary things

Description

Added code to support the ADI EV-COG-AD4050LZ platform. Re-submitted as a new pull request to replace PR #5097.

Status

READY

Migrations

NO

Related PRs

N/A

branch	PR
N/A

Todos

N/A

Deploy notes

N/A

Steps to test or reproduce

N/A

0xc0170 · 2017-09-27T12:47:28Z

retest uvisor

0xc0170 · 2017-09-27T12:54:27Z

..._Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/TARGET_EV_COG_AD4050LZ/device/startup_ADuCM4050.c

+#elif defined(__ICCARM__)
+__root
+#endif
+const uint32_t SECTION_PLACE(blank_checksum[],".checksum") =


How will this work with bootloader?

Either the flash image would need to have the checksum blocks defined or the bootloader would need to write these checksum blocks.

cc @c1728p9

0xc0170 · 2017-09-27T12:59:18Z

..._Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/TARGET_EV_COG_AD4050LZ/device/startup_ADuCM4050.c

+  which address 0x20000000.
+*----------------------------------------------------------------------------*/
+#ifdef __ICCARM__
+void (*__Relocated___Vectors[NVIC_NUM_VECTORS])(void) @(NVIC_RAM_VECTOR_ADDRESS);


is this needed as mbed boot handles nvic reallocation?

Not needed, will remove.

Removed in ce580dd

0xc0170 · 2017-09-27T13:11:37Z

targets/targets.json

@@ -109,8 +109,8 @@
        "extra_labels": ["NXP", "LPC11UXX"],
        "macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
        "supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
-        "device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
-	"default_lib": "small",
+        "device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],


bad rebase?

This is for the target 'LPC11U34_421', probably modified by the git merge. The changes in target.json for the COG4050 platform should just be localized to the "EV_COG_AD4050LZ" section.

Will fix in the next commit.

0xc0170 · 2017-09-27T13:13:01Z

targets/TARGET_Analog_Devices/mbed_rtx.h

+#define OS_CLOCK                26000000
+#endif
+#ifndef MBED_CONF_APP_THREAD_STACK_SIZE
+#define MBED_CONF_APP_THREAD_STACK_SIZE 1024


this is app specific config that by default is 4k in mbed, why is this changing it?

Was failing one of the tests because the creation of multiple threads were overflowing the heap, hence the limitation of the thread stack size.

I believe test should be updated , not target. Target should have default one (all targets are equal).

Either that or there should be some guidelines on what minimal stack and heap sizes are required for passing all the tests.

Either that or there should be some guidelines on what minimal stack and heap sizes are required for passing all the tests.

👍 , can you please for now remote this from a target configuration and move this to the test rather, send a separate patch that we can review?

cc @bulislaw @c1728p9 @pan- for visibility of this

Removed from mbed_rtx.h. However I can't remember which test I had problem with, will try to find it.

0xc0170 · 2017-09-27T13:14:01Z

targets/TARGET_Analog_Devices/mbed_rtx.h

+#define OS_TASKCNT              6
+#endif
+#ifndef OS_MAINSTKSIZE
+#define OS_MAINSTKSIZE          112


arent some of these macros from older RTX version? not valid anymore?

Wasn't quite sure whether these were still needed since the move to RTX5, will remove.

0xc0170 · 2017-09-27T13:19:30Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/spi_api.c

+    SPI_Handle = *obj->pSPI_Handle;
+    SPI_Return = adi_spi_SetMasterMode(SPI_Handle, master);
+    if (SPI_Return) {
+        obj->error = SPI_EVENT_ERROR;


whats the intention with `obj->error`` ? how is it used?

It is there to store any error codes from the adi spi driver

0xc0170 · 2017-09-27T13:21:27Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/serial_api.c

+#if DEVICE_SERIAL_ASYNCH
+uint8_t serial_tx_active(serial_t *obj)
+{
+    return 0;


These async should also not be here, as it's not functional - tests will fail

You mean they should be removed from the source file if not implemented?

That is what I was asking. If this is enabled and has no implementation leads to runtime errors that are harder to catch than simple not defined = not implemented?

0xc0170 · 2017-09-27T13:23:57Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/i2c_api.c

+
+void i2c_reset(i2c_t *obj)
+{
+    return;


why are these empty, even byte write/read

This is not required as adi_i2c_Reset() is called from i2c_init()

In that case yes, but in case of API, as this is HAL API, a user can create I2C API and this should be implemented.

0xc0170 · 2017-09-27T13:25:04Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/analogin_api.c

+
+/** Analogin hal structure. analogin_s is declared in the target's hal
+ */
+typedef struct analogin_s analogin_t;


isn't this defined already in analogin_api header file?

Removed in ce580dd

0xc0170 · 2017-09-27T13:26:24Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/analogin_api.c

+    /* Enable the ADC */
+    adi_adc_Enable (hDevice, true);
+
+    adi_adc_GetBuffer (hDevice, &pAdcBuffer);


adi_adc_GetBuffer (hDevice, &pAdcBuffer); should not have space between function name and arguments, in lot of lines in thsi file it is like that

Fixed in ce580dd

0xc0170 · 2017-09-29T13:38:02Z

Let us know once you update this codebase

- Removed unneeded code from i2c and serial modules.

RonEld · 2017-10-02T07:23:10Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+#define TRNG_CNT_VAL	4095
+#define TRNG_PRESCALER 	2
+
+static ADI_RNG_HANDLE     RNGhDevice;                     /* Memory to handle CRC Device */


why not have ADI_RNG_HANDLE as a member of the trng_t object, and then the trng_t will not be unused parameter. (That's the purpose of the trng_t structure)

RonEld · 2017-10-02T07:27:41Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+// Prescaler: 0 - 10
+// LenReload: 0 - 4095
+#define TRNG_CNT_VAL	4095
+#define TRNG_PRESCALER 	2


what does the values of TRNG_CNT_VAL and TRNG_PRESCALER defined? What do they mean? Do these values gurantee there will be full entropy from the source?

These set the sample length register in the RNG hardware. The sample length register determines the number of samples to accumulate in a CRC register when generating a random number.

I see, thanks, so isn't this dependent on the value of length in trng_get_bytes ?
What if the required length will be larger than the total sample length defined in compilation?

The sample length register value in the HW is not the same as the length you pass into trng_get_bytes. For each random data byte trng_get_bytes requests from the HW, the HW would need to accumulate X number of samples (in this case it uses values derived from clock jitter) before outputting a value, and the sample length register sets this X value. That's why the driver has that bReady flag to indicate whether the accumulation is complete. TRNG_CNT_VAL and TRNG_PRESCALER together define this X value.

I'm sorry, but it's still not clear to me. X number of samples is a constant value, right? I mean, let's say every sample is 32 bit, and X would be 5, this means that every time you ask for random value, you will generate only 160 bits of entropy. Wht if the required random length is 180 bits? If I understand correct, the the bready is set once 160 bits were accumulated, right?

The value of X is not the number of entropy bits you want to generate. X is the number of sample accumulations the RNG hardware runs internally before outputting any entropy bits (the samples come from the clock jitter measurements). The bReady flag indicates the completion of this accumulation process, so when the flag is set, in the current configuration the RNG hardware returns 8-bits of entropy. In order to get 160 bits, the for loop in the trng_get_bytes function will need to loop through 20 times (the bReady flag will need to be set 20 times during this process), and for 180 bits, the loop will need to go through 23 iterations.

I am not sure whether I have answered your question. If you want to know how the hardware generates the entropy, you can have a look at chapter 13 of the processor reference manual:
http://www.analog.com/media/en/dsp-documentation/processor-manuals/ADuCM4050_HRM_0.2.pdf

Thanks, that answers my question

RonEld · 2017-10-02T07:30:05Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+    for (i = 0; i < length; ) {
+        // wait for the RNG ready to give a random number
+        adi_rng_GetRdyStatus(RNGhDevice, &bRNGRdy);
+        if (bRNGRdy) {


what if bRNGRdy will always be false? or some of the times? This means that you will miss some data, and go to next iteration

RonEld · 2017-10-02T07:32:22Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+            output[i++] = (uint8_t) nRandomNum;
+        }
+    }
+    *output_length = length;


see previous comment.
If you get bRNGRdy will be fals some of the times, the collected output will not be length , so you can't set the output size as length, but you should set as the exact collected data length.

RonEld · 2017-10-02T07:39:04Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+        if (bRNGRdy) {
+            // read the random number
+            adi_rng_GetRngData(RNGhDevice, &nRandomNum);
+            output[i++] = (uint8_t) nRandomNum;


output is a buffer of uint8_t. nRandomNum is uint32_t. ALthough you downcast to uint8_t, I assume that adi_rng_GetRngData collects 32 bits of entropy, but you take only 8 bits each time. You loose data this way, and it is likely that the output data will not have full entropy.
It is better to take the full random word and fill it in output buffer, as long as it fits. if length doesn't divide with sizeof(uint32_t). the last collection should only take part of the nRandomNum value

RonEld

I had some questions, but I am mostly not happy with the implementation of trng_get_bytes. I suspect there are scenarios it will not produce good entropy

…ady; - Added a configuration call in trng_init to make sure the TRNG buffering mode is disabled, so only 8-bit bytes are returned; - Moved the TRNG device handle into the trng_t structure; - Fixed some formatting errors in the adc driver.

RonEld · 2017-10-03T08:39:10Z

@0xc0170 Please label this as component:tls so we could track it

RonEld · 2017-10-03T14:00:11Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

    adi_rng_Enable(RNGhDevice, true);
+
+	// Save device handle
+	obj->RNGhDevice = RNGhDevice;


RNGhDevice is located on the stack. when you assign obj->RNGhDevice = RNGhDevice you set obj->RNGhDevice to be point to a variable on the stack, that might be garbage after exiting the function. Does adi_rng_Open allocate memory on the heap?

Do all the adi_xxx functions return an error code? WHat happens if they fail?

@dave-wu Please address the first comment\question that was hidden, It is still relevent

RonEld · 2017-10-03T14:06:23Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/trng_api.c

+        adi_rng_GetRngData(RNGhDevice, &nRandomNum);
+
+        // Save the output
+		output[i] = (uint8_t)nRandomNum;


same comment as before. nRandomNum is uint32_t, and you are taking only 8 bits from it. THis doesn't gurantee sufficient entropy. I suggest you do the loop until i < length/sizeof(uint32_t), and the memcpy(((uint32_t*)output)[i],&nRandomNum, sizeof(uint32_t)) , and after the loop copy the residue (length%sizeof(uint32_t) bytes )
This will also result in fewer calls to Hardware, possibly improving performance

what is the return type of the adi_xxx functions? Can they fail?

Sorry I failed to mention. The function adi_rng_GetRngData outputs either an 8-bit byte or a 32-bit word, depending on whether the TRNG buffering mode is enabled. By default the buffering mode is disabled and it would output an 8-bit byte, so only the LSB in nRandomNum is valid. In the trng_init, I added code to make sure the buffering mode is disabled.

The return values of the adi_xxx functions indicate whether the operation is success or had issues. In the case of adi_rng_GetRngData and adi_rng_GetRdyStatus calls, they would only return an error if the TRNG is not initialized in which case the device handle is invalid.

By default the buffering mode is disabled and it would output an 8-bit byte, so only the LSB in nRandomNum is valid.

I would use masking instead of casting

The return values of the adi_xxx functions indicate whether the operation is success or had issues.

In this case, it is better to check return type, and fail if the internal adi_xxx fail

Will add error checking for the trng_get_byte function.

0xc0170 · 2017-10-05T09:35:43Z

targets/targets.json

+        "supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
+        "macros": ["__ADUCM4050__", "EV_COG_AD4050LZ"],
+        "extra_labels": ["Analog_Devices", "ADUCM4X50", "ADUCM4050", "EV_COG_AD4050LZ", "FLASH_CMSIS_ALGO"],
+        "device_has": ["SERIAL", "STDIO_MESSAGES", "TRNG", "SLEEP", "INTERRUPTIN", "LOWPOWERTIMER", "RTC", "SPI", "I2C", "FLASH", "ANALOGIN"],


I2C is not fully implemented, why are some API missing? This might be case for some other HAL implementations (some functions are empty).

The I2C API's that are not implemented are due to the I2C hardware handling features such as start and stop. There is no way to create only a start or stop condition. Functions such as these are usually used in software I2C implementations.

This should be stated in the code either via comment or git commit msg, I can see lot of empty functions but do not know the reason behind those (to support return 0 for instance). It would be helpful

Comments added to I2C and SPI modules as recommended.

0xc0170 · 2017-10-06T09:30:02Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/gpio_api.c

+{
+    obj->pin = pin;
+
+    if (pin == (PinName)NC)


should be wrapped by { and } ,same for the rest of if in this file (one liners) (line 79, line 137)

0xc0170 · 2017-10-06T09:30:48Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/gpio_irq_api.c

+    uint32_t port = obj->pinname >> GPIO_PORT_SHIFT;
+    uint32_t pin_num = obj->pinname & 0xFF;
+
+    if (event == IRQ_NONE)


{ , also line 251 in this file, please align the code in HAL code files like this one

0xc0170 · 2017-10-06T09:32:27Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/i2c_api.c

+
+int i2c_byte_read(i2c_t *obj, int last)
+{
+    return 0;


Is this limitation of hw or yet not implemented? Please provide more information. Leaving any API empty should have a reasoning .

0xc0170 · 2017-10-06T09:42:23Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/serial_api.c

+static uart_irq_handler irq_handler = NULL;
+int stdio_uart_inited = 0;
+serial_t stdio_uart;
+int rxbuffer[2];


why are these global? I can see these buffers are locally used in one function, could this be local scope then? not certain neither about why 2 are needed (based on the index), but if local scope would be, it would be just one character?

If the buffers are moved to local, UART do not work properly. There are 2 UARTs on ADuCM4050, they may not run at the same baud rate. The spare UART is useful as a debug terminal or a wifi port. Do you want to disable the spare UART here?

The variables stdio_uart_inited and stdio_uart need to be global as they are referenced from mbed_board.c. The rxbuffer and txbuffers can be made static. As mentioned above, ADuCM4050 has two UARTs so it makes sense to provide code to support both even if only one is required for mbed-os.

Understood. if possible, should be local then, or at least these should be made privately to this compilation unit (static).

0xc0170 · 2017-10-06T09:43:01Z

targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/api/sleep.c

+    }
+
+    // if enable, set the bit otherwise clear the bit
+    if (enable)


{ and } around conditions

0xc0170 · 2017-10-06T09:44:14Z

How was this target tested - can you share test results for all 3 toolchains?

0xc0170 · 2017-11-06T10:39:09Z

/morph export-build

/morph uvisor-test

mbed-ci · 2017-11-06T11:37:17Z

Exporter Build : FAILURE

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

0xc0170 · 2017-11-06T14:53:23Z

@dave-wu Can you review the latest exporter build , fails for one exporter (blinky example) - undefined symbols in files that are being added here.

dave-wu · 2017-11-06T21:34:27Z

@0xc0170 The error says it can't find uint16_t type definition, looks like it's an include path issue? What do I need to do to duplicate this test locally?

0xc0170 · 2017-11-07T10:18:56Z

From the log, this example fails:

mbed-os-example-blinky EV_COG_AD4050LZ gnuarmeclipse

therefore import blinky example, use your branch (this patch) as mbed-os lib . Export via mbed export command for gnuarmeclipse. You should then build the exporter project that should produce the same error.

li-ho · 2017-11-07T10:54:21Z

@0xc0170 Those .c files listed in mbed-os\targets\TARGET_Analog_Devices\TARGET_ADUCM4X50\TARGET_ADUCM4050\.mbedignore have not been ignored by gnuarmeclipse project. This is why the makefile of make_gcc_arm can build.

0xc0170 · 2017-11-07T11:17:10Z

@dave-wu @li-ho Thanks for the pointer, https://github.com/dave-wu/mbed-os/blob/9e0e9c8bee1cc2b9d37ad8efbf4e1ea56cad8fff/targets/TARGET_Analog_Devices/TARGET_ADUCM4X50/TARGET_ADUCM4050/.mbedignore - I can see those files are failing for gnuarmeclipse exporter.

Why are these files in the codebase if they are being ignored ?
@theotherjimmy can you have a look at this failing use-case please

li-ho · 2017-11-07T11:25:10Z

@0xc0170 and @theotherjimmy For example, adi_rtc_data.c is already included in adi_rtc.c, therefore, adi_rtc.c is the only file to be compiled in bsp\rtc folder. adi_rtc_data.c must not be compiled.

theotherjimmy · 2017-11-07T14:56:37Z

@li-ho Please do not ignore files that will be used in the build. This will not export correctly on the website, regardless of what the offline exporters do.

Could you refactor your code to avoid #include of C files?

@0xc0170 While this may technically be a bug in the exporter, but I have yet to see a use case for single-file .mbedignore. The above use will break all website exporters, and as such is not a use case for single-file .mbedignore.

li-ho · 2017-11-08T00:02:17Z

@theotherjimmy Those files in bsp folder come from AnalogDevices.ADuCM4x50_DFP.1.1.0.pack of https://www.keil.com/dd2/pack/, and they will be updated independently. I am disallowed to refactor them which will be different from the future pack.

dave-wu · 2017-11-08T01:14:10Z

@theotherjimmy and @0xc0170 As mentioned earlier it is not ideal for us to change the driver code as it will be somewhat more complicated when it comes to update them to newer driver releases in the future. I believe this issue in the exporter should be fixed as the developer shouldn't have to re-organize source files just for the exporter to work. Not sure whether it is possible for the merge to proceed for now with the GNU exporter flagged as an issue to fix down the track?

0xc0170 · 2017-11-08T10:59:51Z

First of all, why some files are being ignored? I've just looked at bsp/rtc as its good example: TARGET_ADUCM4X50/TARGET_ADUCM4050/bsp/rtc/adi_rtc_data.c - this file is a code file that does not compile by itself - does not include what it needs, thus fails to build. The idea here is to include it in another file that pulls in required files and being ignored. I find this a bad practise. Having a file that does not compile by itself introduces the specific order and hierarchy that only leads to problems. Having ignorefile in this case is not a solution to this problem, is it? This becomes obvious with failures above. There are possible solutions to this problem we could do. I do not think having ignore file is the right answer.

How are you exporting your drivers to other enviroment like IAR, uVision, etc? Exluding those files from the workspace? What is the goal with this hierarchy introduced?

I believe this issue in the exporter should be fixed

I do not believe this is a problem with exporters, rather software problem that our tests discovered. It can happen in any enviroment.

@theotherjimmy Those files in bsp folder come from AnalogDevices.ADuCM4x50_DFP.1.1.0.pack of https://www.keil.com/dd2/pack/, and they will be updated independently. I am disallowed to refactor them which will be different from the future pack.

I understand and it's clear, no one would like to do magic for future maintainance, drag-n-drop!
Can these files be fixed now? To make them compiled as a whole in the pack, or at least introduce local fixes in this patch - for this codebase (and mainline them asap). The next update could introduce the fixes that would have the files self-contained and would work with any enviroment.

@dave-wu @li-ho please advise

li-ho · 2017-11-08T12:19:09Z

@0xc0170 and @theotherjimmy

Rename adi_adc_data.c to adi_adc_data.h
adi_flash_data.c to adi_flash_data.h
adi_i2c_data.c to adi_i2c_data.h
adi_rtc_data.c to adi_rtc_data.h
adi_spi_data.c to adi_spi_data.h
adi_tmr_data.c to adi_tmr_data.h

in adi_adc.c include adi_adc_data.h
in adi_flash.c include adi_flash_data.h
in adi_i2c.c include adi_i2c_data.h
in adi_rtc.c include adi_rtc_data.h
in adi_spi.c include adi_spi_data.h
in adi_tmr.c include adi_tmr_data.h

see attached zip file
bsp.zip

Let @dave-wu push the change.

…icking up the ignored files; - Added #includes in BSP data C files so they can be built on their own without mbedignore;

dave-wu · 2017-11-09T03:23:11Z

@0xc0170 Changes pushed, please re-test.

0xc0170 · 2017-11-09T10:42:57Z

/morph export-build

0xc0170 · 2017-11-09T10:43:17Z

/morph build

mbed-ci · 2017-11-09T11:15:36Z

Build : SUCCESS

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

Triggering tests

/morph test
/morph uvisor-test

mbed-ci · 2017-11-09T12:18:16Z

Exporter Build : SUCCESS

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

mbed-ci · 2017-11-09T14:02:24Z

Test : SUCCESS

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

Added support for ADI EV-COG-AD4050LZ platform.

00b1e72

0xc0170 added the needs: review label Sep 20, 2017

dave-wu mentioned this pull request Sep 25, 2017

Adi cog candidate #5097

Closed

theotherjimmy added the scope: new-target label Sep 25, 2017

0xc0170 requested changes Sep 27, 2017

View reviewed changes

dave-wu added 3 commits October 2, 2017 14:28

Fixed issues raised in the feedback from ARM for the ADuCM4050 platform.

ce580dd

Fixed a merge error for LPC11U34_421.

8663958

- Added definiton for i2c_reset;

7cf9bf5

- Removed unneeded code from i2c and serial modules.

RonEld reviewed Oct 2, 2017

View reviewed changes

RonEld suggested changes Oct 2, 2017

View reviewed changes

dave-wu added 3 commits October 3, 2017 14:21

Removed undefined spi slave related functions.

c196ad2

Removed the custom app thread stack size.

d1b81b2

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

RonEld reviewed Oct 3, 2017

View reviewed changes

0xc0170 requested changes Oct 5, 2017

View reviewed changes

0xc0170 reviewed Oct 6, 2017

View reviewed changes

- Removed .mbedignore due to an issue with the eclipse exporter not p…

d5122c5

…icking up the ignored files; - Added #includes in BSP data C files so they can be built on their own without mbedignore;

0xc0170 added ready for merge and removed needs: CI labels Nov 10, 2017

theotherjimmy changed the title ~~Added support for ADI EV-COG-AD4050LZ platform.~~ Add support for ADI EV-COG-AD4050LZ platform. Nov 13, 2017

theotherjimmy merged commit 13d43d7 into ARMmbed:master Nov 13, 2017

theotherjimmy added release-version: 5.6.5 and removed ready for merge labels Nov 13, 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-AD4050LZ platform. #5144

Add support for ADI EV-COG-AD4050LZ platform. #5144

Uh oh!

Conversation

dave-wu commented Sep 20, 2017

Description

Status

Migrations

Related PRs

Todos

Deploy notes

Steps to test or reproduce

Uh oh!

0xc0170 commented Sep 27, 2017

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!

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!

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!

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!

0xc0170 commented Sep 29, 2017

Uh oh!

RonEld Oct 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

RonEld Oct 2, 2017 •

edited

Loading