NCS36510 - i2c, pwm, digitalin failures (CI test shield)

[0xc0170]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
K64F|??

Toolchain:
GCC_ARM

Toolchain version:
4.9.3

mbed-cli version:
1.0.0

meed-os sha:
f6f872a - master

Actual behavior

+------------------+---------------+----------------------------+------------------------------------+--------+--------+---------+--------------------+
| target           | platform_name | test suite                 | test case                          | passed | failed | result  | elapsed_time (sec) |
+------------------+---------------+----------------------------+------------------------------------+--------+--------+---------+--------------------+
| NCS36510-GCC_ARM | NCS36510      | tests-api-digitalio        | Digital I/O on DIO_6/DIO_7         | 0      | 1      | FAIL    | 0.12
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-digitalio        | Digital I/O on DIO_7/DIO_6         | 0      | 1      | FAIL    | 0.12
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-digitalio        | Digital I/O on DIO_8/DIO_9         | 0      | 1      | FAIL    | 0.11
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-digitalio        | Digital I/O on DIO_9/DIO_8         | 0      | 1      | FAIL    | 0.11
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-i2c              | I2C -  EEProm WR 10  Bytes         | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-i2c              | I2C -  EEProm WR 100 Bytes         | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-i2c              | I2C -  EEProm WR 2 Bytes           | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-i2c              | I2C -  EEProm WR Single Byte       | 0      | 0      | ERROR   | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-interruptin      | InterruptIn on DIO_6               | 0      | 2      | FAIL    | 0.17
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-interruptin      | InterruptIn on DIO_7               | 0      | 2      | FAIL    | 0.16
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-interruptin      | InterruptIn on DIO_8               | 0      | 2      | FAIL    | 0.17
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-interruptin      | InterruptIn on DIO_9               | 0      | 2      | FAIL    | 0.17
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Duty Cycle 100ms             | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Duty Cycle 10ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Duty Cycle 30ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Frequency 100ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Frequency 10ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_0 Frequency 30ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Duty Cycle 100ms             | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Duty Cycle 10ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Duty Cycle 30ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Frequency 100ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Frequency 10ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_1 Frequency 30ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Duty Cycle 100ms             | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Duty Cycle 10ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Duty Cycle 30ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Frequency 100ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Frequency 10ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_2 Frequency 30ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Duty Cycle 100ms             | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Duty Cycle 10ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Duty Cycle 30ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Frequency 100ms              | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Frequency 10ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | PWM_3 Frequency 30ms               | 0      | 0      | SKIPPED | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-pwm              | Pwm object definable               | 0      | 0      | ERROR   | 0.0
          |
| NCS36510-GCC_ARM | NCS36510      | tests-api-spi              | SPI - SD card exists               | 0      | 1      | FAIL    | 0.12
          |
| NCS36510-GCC_ARM | NCS36510      | tests-assumptions-analogin | tests-assumptions-analogin         | 0      | 1      | ERROR   | 70.89
          |
| NCS36510-GCC_ARM | NCS36510      | tests-assumptions-pwmout   | tests-assumptions-pwmout           | 0      | 1      | ERROR   | 65.5
          |
+------------------+---------------+----------------------------+------------------------------------+--------+--------+---------+--------------------+

Various failures for target NCS36510. This test was done using out of box shield, did not define any specific pins. I had to commented out BusOut and AnalogIn because of #3508

@radhika-raghavendran @pradeep-gr

[radhika-raghavendran]

@0xc0170
DIO tests "tests-api-digitalio | Digital I/O on DIO_6/DIO_7" is failing because the DIO_7 pin is not connected to any GPIO line. I have tested DIO_6(D6) for toggling low to high and vice versa and verified working by hooking on an oscilloscope. The IO lines DIO_7, DIO_8 and DIO_9 are NC on NCS36510 board, hence the 4 tests related to these pins are failing.
InterruptIn tests "tests-api-interruptin | InterruptIn on DIO_6" is also failing for the above mentioned reason. I have tested InterruptIn functionality using DIO_5 instead of DIO_7 and verified working fine. All 4 tests related to the above mentioned pins are thus failing for InterruptIn tests.

[0xc0170]

@radhika-raghavendran Thanks for the update. As I understand some of arduino pins are defined as NC, therefore our CI shield tests fail. I've just sent PR to add a check if pin is not NC, to easily detect that pins we test are well defined (=connected).

What about the rest of the tests from the above report?

[radhika-raghavendran]

@0xc0170 Can you tell us the method to reproduce this set of results? I cloned the ci-test-shield repo and ran the tests according to the instructions given in https://github.com/ARMmbed/ci-test-shield. I need to run each of the tests individually, I don't get a consolidated report like you do.

[0xc0170]

mbed test -n tests-api-* --app-config .\mbed_app.json

[radhika-raghavendran]

@0xc0170
PWM on NCS36510 cannot operate on GPIO10(D6) and D9 is NC. Hence PWM2 and PWM3 definitions cannot be used in the ci-test for PWM.
Also, NCS36510 does not have the capability to change the frequency/period. All tests for frequency and duty cycle(which rely on frequency internally) in the pwm test are invalid for NCS36510.
I had previously requested the ARM mbed team to let me know of a way in which we can signal that the PWM API is not supported by the silicon. Since the API does not return any value, it is not possible to return an unsupported/failure from the API.

[0xc0170]

I had previously requested the ARM mbed team to let me know of a way in which we can signal that the PWM API is not supported by the silicon. Since the API does not return any value, it is not possible to return an unsupported/failure from the API.

Please create an issue to track this and discuss further.

PWM on NCS36510 cannot operate on GPIO10(D6) and D9 is NC. Hence PWM2 and PWM3 definitions cannot be used in the ci-test for PWM.

Tests should not fail but might result as "Not supported" in this case. If defined PIN is NC. This could be also proposed in ci-shield test repository. We can clearly see that some targets do not fully support all arduino headers and pin requirements.

cc @BlackstoneEngineering

[BlackstoneEngineering]

cc @maclobdell

To signal that the PWM API is not supported you would simply not define it : https://github.com/ARMmbed/ci-test-shield/blob/master/TESTS/assumptions/PwmOut/PwmOut.cpp#L19

The problem here is the board supports PWM, but not the full API. So far we do not have tests for this but instead assume all API's are fully implemented.

@screamerbg This may be a good use case for why we should have tiered tests on the CI Test shield? Levels of compliance type thing?

[pradeep-gr]

@maclobdell @0xc0170 @danish-iftikhar
I2C issues on I2CEeprom is due to bugs in the library. I found and fixed some bugs(details listed below). I think still there are many. I am not a C++ expert so not able to fix those.

1. In function I2CEeprom::read(size_t address, char &value):
   line 'm_i2c.write(m_i2cAddress, values, 2)' should be changed to 'm_i2c.write(m_i2cAddress, values, 2, 1)' /* TO enable repeat start */
2. same bug in function 'I2CEeprom::read(size_t address, char *buffer, size_t size)'
3. In function 'I2CEeprom::write(size_t address, const char *buffer, size_t size)'
   line 'if (m_i2c.write(m_i2cAddress, values, 2, true) != 0)' should be changed to 'if (m_i2c.write(m_i2cAddress, values, 2, false) != 0)' To avoid stop between to write functions

cpp file attached FYR

I2CEeprom.zip

Also there are some fixes from our side too. I do not want to update 640K PR with I2C changes. Let me know when to raise PR fro I2C changes.

[0xc0170]

Also there are some fixes from our side too. I do not want to update 640K PR with I2C changes. Let em know when to raise PR fro I2C changes.

Anytime ,please send a separate PR for a new set of logical changes - in this case I2C fixes.

I2C issues on I2CEeprom is due to bugs in the library.

If you can reference file lines directly, would be easier to review. We should look at the data via logic analyzer to see what is going on the bus to confirm the bug. Write data should look like this : http://www.jechavarria.com/wp-content/uploads/2013/06/write_page.bmp for instance. Quick look at the source code, looks like it is wrong, as it sends address, repeated is false, thus should send stop right after and then read/write data..

[pradeep-gr]

@0xc0170
I will raise separate PR for I2C.
You are correct data should match as per the I2C protocol on logic analyzer for both read and write.
Find line numbers for the issues.

1. Line no.33
2. Line no. 48
3. Line no. 102

Read sequence should look like this:

[maclobdell]

@pradeep-gr Thanks a lot for your investigation on this. In your local repository, if you create a new branch that just contains commits for your i2c changes that are made on top of the master branch of the main repo, you can push to your fork of the main repo on your github account, then do a pull request from that i2c changes branch in your fork. Using multiple branches is a handy way to have multiple pull requests ongoing for different changes/features that don't interact with each other. I'm a bit new to this stuff myself and just started using this method. Sorry if this is familiar to you already. Thanks again.

[pradeep-gr]

@maclobdell @0xc0170
Point no. 3 is invalid. No need to change @ line no 102. Other two points are valid.
Thanks for the info Mac. I am also new to this :)

[pradeep-gr]

@maclobdell @0xc0170
We need some delay after write to I2CEEPROM (to write to take effect) as per microchip forum.
I am using 5 msec of delay between write and read in I2C.cpp file and all I2C test cases are passing.
I suggest you to update library with delay.