Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

02-tests/task 03 Release 2016.07 - RC1 #24

Closed
BytesGalore opened this issue Jul 27, 2016 · 14 comments
Closed

02-tests/task 03 Release 2016.07 - RC1 #24

BytesGalore opened this issue Jul 27, 2016 · 14 comments

Comments

@BytesGalore
Copy link
Member

BytesGalore commented Jul 27, 2016

Task # 03

Perform a subset of tests (!= subset from Task #02) on samr21-xpro node:

  • bitarithm_timings
  • bloom_bytes
  • coap
  • conn_ip
  • cpp11_condition_variable
  • cpp11_mutex
  • cpp11_thread
  • driver_adt7310 -> results in expected behaviour: Initializing ADT7310 sensor... [Failed]*
  • driver_at30tse75x
  • driver_at86rf2xx
  • driver_bh1750 -> results in expected behaviour: the lux value is always 0, since no BH1750FVI ambient light sensor is attached
  • driver_bmp180
  • driver_dht
  • driver_enc28j60 -> results in expected behaviour: ifconfig doesn't show up the ethernet device since its not attached
  • driver_encx24j600
  • driver_hdc1000
  • driver_hih6130 -> results in expected behaviour: Initializing HIH6130 sensor at I2C_0, address 0x27... [OK] Communication error: -1, since no HIH6130 sensor is attached
  • driver_ina220
  • driver_isl29020
  • driver_isl29125 -> results in expected behaviour: Initializing ISL29125 sensor at I2C_0... [Failed]
  • driver_kw2xrf
  • driver_l3g4200d
  • driver_lis3dh -> results in expected behaviour: Initializing LIS3DH sensor... [Failed]
  • driver_lis3mdl
  • driver_lps331ap
  • driver_lsm303dlhc -> results in expected behaviour: Initializing LSM303DLHC sensor at I2C_0... [Failed]
  • driver_mag3110
  • driver_mma8652
  • driver_mpl3115a2 -> results in expected behaviour: Initializing MPL3115A2 sensor at I2C_0... [Failed]
  • driver_mpu9150
  • driver_mq3
  • driver_nrf24l01p_lowlevel -> results in expected behaviour: initializing the transceiver it fails with all read registers are 0
  • driver_nrfmin
  • driver_nvram_spi
  • driver_pcd8544 -> runs but doesn't give feedback if a display is actually attached
  • driver_pir
  • driver_servo
  • driver_si70xx -> results in expected behaviour: Testing sensor communication...[Failed], since no SI7021 temperature and humidity sensor is attached
  • driver_srf02
  • driver_srf08
  • driver_tcs37727 -> results in expected behaviour: Initializing TCS37727 sensor at I2C_0... [Failed], since its not attached
  • driver_tmp006
  • driver_xbee
  • emb6
  • fault_handler
  • float
  • fmt_print
  • gnrc_ipv6_ext
  • gnrc_sixlowpan
  • irq
  • leds
  • libfixmath
  • lwip
  • malloc
  • minimal
  • msg_send_receive (fixed: tests: msg_send_receive: fix "sent ptr goes out of scope" bug RIOT#5701)
  • msg_try_receive
  • mutex_order
  • mutex_unlock_and_sleep
  • netdev2_test
  • netstats_l2
  • nhdp
  • periph_adc
  • periph_cpuid
  • periph_dac
  • periph_gpio
  • periph_hwrng
  • periph_i2c -> initialization of the i2c works
  • periph_pwm
  • periph_rtc
  • periph_rtt
  • periph_spi
  • periph_timer
  • periph_uart -> initialized UART device 1 with a 9800 baudrate
  • pipe
  • pkg_cmsis-dsp
  • pkg_jsmn
  • pkg_micro-ecc
  • pkg_u8g2
  • posix_semaphore -> TEST4 fails due to timer drift, i.e. ~265 us difference to expected 1s
  • posix_sleep
  • pthread
  • pthread_barrier
  • pthread_cleanup
  • pthread_condition_variable
  • pthread_cooperation
  • pthread_rwlock
  • pthread_tls
  • saul
  • sched_testing
  • shell
  • sizeof_tcb
  • slip
  • struct_tm_utility
  • thread_basic
  • thread_cooperation
  • thread_exit
  • thread_flags
  • thread_flood
  • thread_msg
  • thread_msg_avail
  • thread_msg_block_wo_queue
  • thread_msg_block_w_queue
  • thread_msg_seq
  • warn_conflict
  • xtimer_drift -> after a handfull min running drift/jitter max: ~170 us
  • xtimer_hang
  • xtimer_longterm
  • xtimer_msg
  • xtimer_msg_receive_timeout
  • xtimer_now64_continuity
  • xtimer_remove
  • xtimer_reset
  • xtimer_usleep_until
  • zep

list made manually by executing:

ls -1a | sed  -e 's/^/- [ ] /'

in RIOT/tests and removing unittests et al. from the list

@kYc0o kYc0o mentioned this issue Jul 27, 2016
39 tasks
@BytesGalore
Copy link
Member Author

test/msg_send_receive fails on the samr21-xpro Is this already known?

@kYc0o
Copy link
Contributor

kYc0o commented Jul 27, 2016

Not to my knowledge. It's supposed to be a reference board so most of the code should work. How it fails?

@BytesGalore
Copy link
Member Author

Basically the test state its failed, which results from the if-condition for the content received in the messages does not match [1]

[1] https://github.com/RIOT-OS/RIOT/blob/master/tests/msg_send_receive/main.c#L53

@kYc0o
Copy link
Contributor

kYc0o commented Jul 27, 2016

Humm... ok I'll try to reproduce.

@BytesGalore
Copy link
Member Author

seems that something is messed up for the last iteration.
I printed the values of counter and msg_resp.content.ptr:

# main(): This is RIOT! (Version: 2013.08-10643-gb5cb6-user01-LLED-E6410)
# Incremented counters to 1 and 1
# resp val: 1, counter: 1
# Incremented counters to 2 and 2
# resp val: 2, counter: 2
# Incremented counters to 3 and 3
# resp val: 3, counter: 3
# Incremented counters to 4 and 4
# resp val: 4, counter: 4
# Incremented counters to 5 and 5
# resp val: 5, counter: 5
# Incremented counters to 6 and 6
# resp val: 6, counter: 6
# Incremented counters to 7 and 7
# resp val: 7, counter: 7
# Incremented counters to 8 and 8
# resp val: 8, counter: 8
# Incremented counters to 9 and 9
# resp val: 9, counter: 9
# Incremented counters to 10 and 10
# resp val: 841, counter: 10
# Test failed.

@kYc0o
Copy link
Contributor

kYc0o commented Jul 27, 2016

Uhm... yeah I'm having the same problem. We need to open an issue for that and try to solve it. Else at least leave the issue open for the next release and solve it asap.

@BytesGalore
Copy link
Member Author

ok, I created an issue RIOT-OS/RIOT#5699
I assigned you, but feel free to reassign.

@BytesGalore
Copy link
Member Author

alright next:
test/posix_semaphore fails on performing the last test, i.e. TEST4.
It seems the sem_timedwait(...) call doesn't wait the desired period.

@BytesGalore
Copy link
Member Author

beside PRIu64 does not seem to work on the samr21-xpro,
expected, e.g.:
first: waited 1000134 usec
actually got:
first: waited lu usec

@kYc0o
Copy link
Contributor

kYc0o commented Jul 27, 2016

uhm... maybe it needs a special module as for floating point numbers?

@miri64
Copy link
Member

miri64 commented Jul 27, 2016

That's not floating points that's long integers ;-). Remember RIOT-OS/RIOT#1891?

@kYc0o
Copy link
Contributor

kYc0o commented Jul 27, 2016

OK so it needs to load that module for samr21. Can it be done on the Makefile?

@miri64
Copy link
Member

miri64 commented Jul 27, 2016

There is no such mudule for long int at least not on the RIOT side. But we can hack something together... But since we decided yesterday to postpone this for next release I would propose to do so and do for now as we always did: ignore this kind of output for now :D

@BytesGalore
Copy link
Member Author

Regarding the fail for test/posix_semaphore TEST4, I have a difference of ~265 us between the actual wait time vs the expected.
I guess this corresponds with the timer drifts so basically this test succeeded :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants