| ... | @@ -3,7 +3,6 @@ |
... | @@ -3,7 +3,6 @@ |
|
|
<br />
|
|
<br />
|
|
|
|
|
|
|
|
## Why does the node ID on the platform Tmote not match with the observer ID?
|
|
## Why does the node ID on the platform Tmote not match with the observer ID?
|
|
|
|
|
|
|
|
There are two possible reasons why this could happen:
|
|
There are two possible reasons why this could happen:
|
|
|
- Binary patching failed for some reason, e.g. because the uploaded execute is not an elf file or the symbol `FLOCKLAB_NODE_ID` does not exist in the binary.
|
|
- Binary patching failed for some reason, e.g. because the uploaded execute is not an elf file or the symbol `FLOCKLAB_NODE_ID` does not exist in the binary.
|
|
|
- You are trying to read the node ID from the EEPROM on the Tmote. The ID stored in the EEPROM can be overwritten by the users and is therefore not reliable. If you still want to use this method, you need to do the mapping by yourself. You could first run a test to read the current IDs, do the mapping and then run another test to write the desired node IDs (e.g. [Contiki](http://contiki.sourceforge.net/docs/2.6/a01425_source.html) provides a function to write the EEPROM).
|
|
- You are trying to read the node ID from the EEPROM on the Tmote. The ID stored in the EEPROM can be overwritten by the users and is therefore not reliable. If you still want to use this method, you need to do the mapping by yourself. You could first run a test to read the current IDs, do the mapping and then run another test to write the desired node IDs (e.g. [Contiki](http://contiki.sourceforge.net/docs/2.6/a01425_source.html) provides a function to write the EEPROM).
|
| ... | @@ -19,3 +18,14 @@ There are several possible reasons why the data trace results could be empty: |
... | @@ -19,3 +18,14 @@ There are several possible reasons why the data trace results could be empty: |
|
|
- Use of low-power mode: you cannot use deep sleep modes while using data trace since the high frequency clock must be running all the time.
|
|
- Use of low-power mode: you cannot use deep sleep modes while using data trace since the high frequency clock must be running all the time.
|
|
|
|
|
|
|
|
<br />
|
|
<br />
|
|
|
|
|
|
|
|
## Why are the GPIO tracing results empty?
|
|
|
|
Make sure you have selected the correct pins for tracing ([see GPIO pin mappings](/Man/GpioAssignmentTargetAdapter)) and ensure the pins are configured as outputs in your code. Also, keep in mind that the LED must keep its state for at least 200ns in order to see the state change (tracing service has a sampling rate of ~10MHz).
|
|
|
|
|
|
|
|
<br />
|
|
|
|
|
|
|
|
## Why does GPIO tracing fail with the error `buffer overrun detected`?
|
|
|
|
A buffer overrun can occur e.g. if one of the traced pins is in a floating state and toggles uncontrollably. This will fill up the tracing buffer within fractions of a second and cause a buffer overrun, whereafter the tracing service will be stopped on that observer. Solution: make sure all the traced pins are always in a defined state.
|
|
|
|
Note: by default, tracing only starts 1s after the test to avoid capturing many erratic toggles at MCU startup. If your program takes longer than that to fully initialize the MCU, you can extend this [tracing offset in the XML config file](https://gitlab.ethz.ch/tec/public/flocklab/wiki/-/wikis/Man/XmlConfig#gpio-tracing-service-configuration).
|
|
|
|
|
|
|
|
<br /> |
|
|
|
\ No newline at end of file |
