mfw issueshttps://gitlab.syscop.de/TOPCORE/mfw/-/issues2017-05-21T08:27:46Zhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/1I2C different rate support2017-05-21T08:27:46ZFabian GirrbachI2C different rate supportCurrently set to 100kHZ.
//! If the parameter \e bFast is \b true, then the master block is set up to
//! transfer data at 400 Kbps; otherwise, it is set up to transfer data at
//! 100 Kbps. If Fast Mode Plus (1 Mbps) is desired, sof...Currently set to 100kHZ.
//! If the parameter \e bFast is \b true, then the master block is set up to
//! transfer data at 400 Kbps; otherwise, it is set up to transfer data at
//! 100 Kbps. If Fast Mode Plus (1 Mbps) is desired, software should manually
//! write the I2CMTPR after calling this function. For High Speed (3.4 Mbps)
//! mode, a specific command is used to switch to the faster clocks after the
//! initial communication with the slave is done at either 100 Kbps or
//! 400 Kbps.Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/2Check out functionality of issue tracker2017-05-21T08:27:46ZThorbjörn JörgerCheck out functionality of issue trackerJonas will know if the issue tracker is worth it's moneyJonas will know if the issue tracker is worth it's moneyJonas SchlagenhaufJonas Schlagenhaufhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/3Delayed relaying of TAS messages on FC2017-05-21T08:27:46ZThorbjörn JörgerDelayed relaying of TAS messages on FC@Martin.dold @evileli @Tobias.paxian @julian.reimer TAS read-out on ArmFC seems to be instant, receiving on FC seems to be already delayed, receiving on GS is delayed by 2-3 s. Meanwhile IMU data taken directly on FC are available on GS ...@Martin.dold @evileli @Tobias.paxian @julian.reimer TAS read-out on ArmFC seems to be instant, receiving on FC seems to be already delayed, receiving on GS is delayed by 2-3 s. Meanwhile IMU data taken directly on FC are available on GS without any noticable delay.Martin DoldMartin Doldhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/4Servo for aileron doesn't work properly from start2017-05-21T08:27:46ZThorbjörn JörgerServo for aileron doesn't work properly from startHi Jungs,
@benedikt.schleusener: bitte bei @thorbjoern.joerger melden und weiteres Vorgehen besprechen, da ein servo wohl futscht ist.
ich saß eben noch mit Thor zusammen am FC und wir haben folgendes getestet und herausgefunden....Hi Jungs,
@benedikt.schleusener: bitte bei @thorbjoern.joerger melden und weiteres Vorgehen besprechen, da ein servo wohl futscht ist.
ich saß eben noch mit Thor zusammen am FC und wir haben folgendes getestet und herausgefunden.
WICHTIG: Im FC ist noch die Debugging Firmware von gerade geflasht! Wer den FC einschaltet, sollte das unten beschriebene Szenario nachstellen können! Es ist debugging code geflasht im FC und der FC sollte so nicht für weitere Tests verwendet werden ;-)
Test-Umgebung:
- GS nicht aktiv/involviert!
- Im FC haben wir ein paar Debugging Zeilen hinzugefügt, um PB-Nachrichten von der GS zu simulieren (see commit embMasterDude: b28d540218f52c862568d946dd89e03191c0c2aa)
- Verwendete PB message aus betCOM: http://gitlab.syscop.de/highwind/betCOM/commit/a46c40db202090d7e224435462671f0e5f5ea94e
- angesteuert wurden elevator, rudder und aileron. Es wurden für alle der gleiche debugging code zum ansteuern verwendet.
Ergebnis:
- Thor hat die im EEPROM gespeicherten Limits des aileron-right dudes geprüft und alles scheint in Ordnung.
- elevator und rudder haben auf Anhieb funktioniert! Beide bekamen alle 10ms Stellwerte zwischen 900 und 2100 zugeschickt. Verhalten haben Thor und ich zusammen optisch geprüft und der Test galt für beide als bestanden!
- in gleicher Art und Weise wie elevator & rudder haben wir dann auch zusätzlich aileron-right angesteuert. aileron-right reagiert aber nicht gewünscht:
-- aileron-right (AR) bekommt Stelltwerte, aber er reagiert nicht immer entsprechend darauf.
-- während elevator & rudder die bewegung (900 ... 2100; 900 ... 2100) sauber ausgeführt haben, kam AR regelmäßig ins stocken.
-- AR servo ist verdammt heiß geworden. Vorübergehendes Fazit laut Thor: servo ist wohl hinüber!
Fazit:
- Der beschriebene Bug von Jonas & Elias, dass aileron-right nicht geht, ist wohl auf einen HW bug zurück zu führen.
- Laut Aussage von @evileli & @jonas.schlagenhauf, wurden elevator & rudder erfolgreich getestet. Das konnte heute nachgestellt werden.
- Laut Aussage von Elias & Jonas kann GS und servo dude selbst als Fehlerquelle ausgeschlossen werden. Ebenso wurden von der GS gesendete Nachrichten wohl erfolgreich vom FC empfangen.
- Der heutige Test schließt eine Fehlfunktion im FC vorerst aus, wobei die Kommunikation GS-FC im heutigen Test nur simuliert wurde. Mit der obigen Aussage von Jonas & Elias sind die Fehlerquellen GS, FC und Servoe-Dude allerdings Software-seitig erstmal auszuschließen.
Ich hoffe ich habe an alles gedacht. Falls ihr überhaupt bis hier her gelesen habt ;-)
Greetz und angenehmen Feierabend,
@Martin.dold
Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/5Mask values send to servo dudes, otherwise limits are accidentially set2017-05-21T08:27:46ZThorbjörn JörgerMask values send to servo dudes, otherwise limits are accidentially setLimit values send to servo dudes to a range from 0-2^14-1 aka &~0xC000
@evileli, @Martin.dold Limit values send to servo dudes to a range from 0-2^14-1 aka &~0xC000
@evileli, @Martin.dold Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/6I²C generic bus management2017-05-21T08:27:46ZThorbjörn JörgerI²C generic bus managementDevelop a system for dynamically allocating and prioritising I²C bus access for different I²C sensors on the same bus.Develop a system for dynamically allocating and prioritising I²C bus access for different I²C sensors on the same bus.Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/7Finalize testing communication between flightcontrollers using latest serial ...2017-05-21T08:27:46ZMartin DoldFinalize testing communication between flightcontrollers using latest serial protocol with CRCWhat's done so far
---
* Against background of issue #29 (in HIGHWIND/Groundstation) we advanced the serial protocol (sproto.c/.h) to calculate and verify CRCs for transmitted telegrams.
* The integration of the updated sources (sp...What's done so far
---
* Against background of issue #29 (in HIGHWIND/Groundstation) we advanced the serial protocol (sproto.c/.h) to calculate and verify CRCs for transmitted telegrams.
* The integration of the updated sources (sproto.c/.h) into embMasterDude and HIGHWIND/Groundstation was done yesterday (20.05.16) by @jonas.schlagenhauf and @Martin.dold. In embMasterDude feature/sproto-crc is even merged back to develop.
* We had the flightcontroller board(s) in the lab for testing. We saw that MPU9250 data sent from FC to GS was visualized correctly -> communication from FC to GS works fine so far.
Remaining TODOs
---
What remains as TODOs for testing is:
* **Communication from GS to FC**: Sending servo values to the FC is not tested yet. However, this is expected to be working fine with high probability.
* **Communication from FC_arm** (= FC board plcaed on the arm) **to FC**: the serial protocol is used between communication of TAS data from FC_arm to FC too. This communication currently is unidirectional, i.e. from FC_arm to FC only. It can be tested by flashing the latest sources to FC_arm, connecting both boards and turn on both boards. The FC is already flashed with latest sources during testing yesterday (see above).
* **Remount everything in hangar again** and check if using CRCs solves issue #29.
Concrete task of this ticket
---
@jonas.schlagenhauf and @benedikt.schleusener agreed to **meet up on Monday (23.05.16) at 11.00 in the lab**. They would like to finalize the testing tasks described above. **@evileli : Please assists the guys!** Otherwise, I would be available Monday (23.05.16) at 15.30 for assistence.
* @benedikt.schleusener : Please mount a new cable to connect FC_arm and FC boards over UART connectors mounted on the boards. We should have such a cable in the lab to have a similar setup like in the hangar.
* @evileli / @benedikt.schleusener : Please check how to power up the FC_arm board in the lab using the lab power supply. The FC_arm has no voltage regulator (small TI PCB) mounted on the board. Can we simply connect the board to the power supply? Or do we need to take the regulated power from the FC and forward it to FC_arm? I powered up FC_arm in the lab a few weeks ago but I wasn't sure about it anymore, sorry. And I didn't want to brick the board yesterday as there was no UART cable available for testing anyway.
* @evileli : Checkout 965a617ce7176e1e4b1d21fbbf36d125bda2f67d
* @evileli : Compile the testapp _test-tube-angle-sensor_ and flash it to the FC_arm board. (Yes, the main() to be run on the FC_arm is currently still named testapp. I will rename the file and move the main() to proper location once everthing is working fine!).
* @evileli : Connect FC_arm and FC using new UART cable provided by Ben. Connect _FC UART 1 connector_ to _FC_arm UART 1 connector_.
* @evileli / @jonas.schlagenhauf : Test complete communication flow! The GS should see MPU9250 data and TAS data in the visualizer!
Debug connection to FC boards
---
Our wiki holds a picture that shows how to connect the debugger to FC boards: http://wiki.syscop.de/RS485-GS-to-FC
Additionally, attached picture shows the connection of debug pins on the FC board:
![IMG_20160330_190637](/uploads/8225eb43271f97c091e0516918554bb2/IMG_20160330_190637.jpg)
Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/8FC_arm not talking to FC2017-05-21T08:27:46ZElias RoschFC_arm not talking to FCToday we ( @jonas.schlagenhauf, @benedikt.schleusener, @evileli ) were trying to attach BabyBetty to the carousel.
FC <-> GS : no problems
FC <-> FC_arm : not working.
Possible reasons:
- Indeed there appeared the weird HWREG...Today we ( @jonas.schlagenhauf, @benedikt.schleusener, @evileli ) were trying to attach BabyBetty to the carousel.
FC <-> GS : no problems
FC <-> FC_arm : not working.
Possible reasons:
- Indeed there appeared the weird HWREG-command which Thor introduced some time ago in ti's ssi.c-library. Probably while merging old features into develop.
Possible Fixes:
- @evileli already fixed the file ssi.c on the current develop branch.
- @Martin.dold The commit used to flash the FC_arm (965a617c) still has that weird command in line 251. Before flashing the FC_arm this should be changed in ssi.c:
wrong: HWREG(ui32Base + SSI_O_CR1) = ui32RegVal + 0x400;
correct: HWREG(ui32Base + SSI_O_CR1) = ui32RegVal;
Unfortunately for some reason I was not able to flash the FC_arm with the debug-board (no idea how the cables should be connected --> @thor maybe documentation in wiki).
Other than that test communication without that weird command. @Martin.dold That may also fix the issue where FC__arm jumps into FaultISR.
Hopefully communication between FC and FC_arm will be fixed with that. If not: Find reason why not!
Cheers.
Thorbjörn JörgerThorbjörn Jörgerhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/9Blowing on the FC increases the rate of CRC errors significantly2017-05-21T08:27:46ZThorbjörn JörgerBlowing on the FC increases the rate of CRC errors significantlyI brake together @Martin.dold @jonas.schlagenhauf @evileli @julian.reimer
I understand only trainstation ...
Please help me to understand the bug to provide meaningful help here.
Edit: Answered questions. Problem stays the same bet...I brake together @Martin.dold @jonas.schlagenhauf @evileli @julian.reimer
I understand only trainstation ...
Please help me to understand the bug to provide meaningful help here.
Edit: Answered questions. Problem stays the same between betCOM 2.2.0 and 2.3.0. Whole project moved now forward to betCOM 2.3.0-alpha1
Setup
---
* What version is used on FC-ARM? a2afa0ab
* What modules are enabled in FC-ARM firmware? [See here](http://gitlab.syscop.de/highwind/embmasterdude/blob/e33e2066ea379fa9472e5dc8a5fbf07906af49b7/app/fc-arm/mfw-config.h)
* Are the two FCs connected with each other in this setup? No. Only ARM-FC to GS.
* What version is used on GS? [0e600939](http://gitlab.syscop.de/highwind/highwind/commit/0e600939ed59fb7dd8999ee7339eae2a75b3693f)
* How did we check for the CRC errors? I expect by checking the command line of GS software? Yes.
* Is the error reproducable? How to reproduce the error? Yes, just blow on it.
* How much "blowing" is required? Mild blowing, like blowing out a couple of candles, but not as much as [on your 90th birthday](https://www.youtube.com/watch?v=hDLDFI6hGc4).
* Where to blow exactly? Directly on the controller.
* Did you test in the lab or in the hangar? Lab.
* How can SW behaviour be effected by such phyiscal influence? Doesn't that point to a HW error some where? Broken/unstable cables, wires, soldering points ... ?! My intuition so far points to two possible effects:
* <s>Blowing changes the temperature of the oscillator, thus leading to a baud rate mismatch between FC-ARM and GS.</s>
* <s>Increasing the package length by activating the tube angle sensors enhances the probability of a baud rate mismatch.</s> edit: also short messages with CRC errors
Source of the problem
----
* <s>Physical manipulation of the connection cable (also induced by blowing) increases CRC error rate @benedikt.schleusener</s> (edit: not the source)
* <s>Packages containing longer runs of zeros (TAS sensor not connected, thus reading in only zeros) are more susceptible to bit misalignment</s> (edit: not the source)
* <s>-O4 (122k main loops / sec) is to much optimization ... -O3 (114k main loops / sec) works fine and still much better than debug (49k main loops / sec)</s>
* edit: not the source. Since hardware rework (resoldering of wires, -O3 works better than debug)
* Source of the problem is <b>definitely the Flight Controller</b>. Review of the signal on the Tx of the µC with the oscilloscope shows the missing bytes.
More info
----
* Testing with feature/crcdebug and sending the same first package each time reveals that messages are missing single bytes or have up to nine additional bytes. This leads to using the wrong bytes as CRC value as well as mismatched length information. This might be an issue with the ringbuffer.
<pre>
Received message yields right CRC (be8f/be8f). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00|10|91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|
Received message yields wrong CRC (1ff1/8fde). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|be|
Received message yields right CRC (be8f/be8f). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00|10| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|
Received message yields wrong CRC (1ff1/8fde). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|be|
Received message yields wrong CRC (3bca/ca03). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 25|52|0b|0a|07|08|00|10|91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|
Received message yields wrong CRC (5610/08ca). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00|10|25|52|0b|0a|07|08|00|10|91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|
Received message yields wrong CRC (1ff1/8fde). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|be|
Received message yields wrong CRC (3bca/ca03). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 25|52|0b|0a|07|08|00|10|91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|
Received message yields wrong CRC (1ff1/8fde). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|be|
Received message yields wrong CRC (1ff1/8fde). Received message: 2a|45|12|07|08|00|10|f1|c3|f5|25|52|0b|0a|07|08|00| 91|b7|f4|25|18|00|5a|0b|0a|07|08|00|10|c8|9f|f4|25|18|00|8a|01|1f|0a|07|08|00|10|b8|99|ed|25|2a|0a|08|80|11|10|80|07|18|a0|92|02|32|08|08|ca|03|10|c4|02|18|72|be|
</pre>
* <s>The last byte in the ringbuf is always 0x00</s> edit: this is a feature, not a bug
* Messages containing the sequence 0x00 0x01 seem to be more succeptible for CRC errors <s>(perhaps frequency mismatch again)</s> edit: frequency alignment is fine.
* Being connected over CCS seems to reduce the CRC error rate drastically.
Brainstroming on possible source
---
* <s>Error in the nano-pb implementation</s> ... edit: might be a problem to use nanopb-0.3.4 for code, but 0.3.6-dev for generation oO?!
* Moved both versions to nanopb-0.3.6(-highwind). Didn't solve the problem.
* Generated the serialized pb message only once and repeatedly sent it. Same problem, so nanopb_encode is not the problem.
* Error in the hal_uart implementation
Solution
---
See commit f564a739Martin DoldMartin Doldhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/10Generate new protobuf message Debug which contains Debug information2017-05-21T08:27:46ZThorbjörn JörgerGenerate new protobuf message Debug which contains Debug informatione. g. Main loops, received crc errors etc.
Please mention important data here. I will the write the protobuf messages:
Debug data so far:
- Main loops
- CRC errors
- Time of serialization
- ... ?
@Martin.dold @evileli e. g. Main loops, received crc errors etc.
Please mention important data here. I will the write the protobuf messages:
Debug data so far:
- Main loops
- CRC errors
- Time of serialization
- ... ?
@Martin.dold @evileli Thorbjörn JörgerThorbjörn Jörgerhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/11NC5623 broken on FC No. 32017-05-21T08:27:46ZThorbjörn JörgerNC5623 broken on FC No. 3Please replace the IC NCP5623 on FC No. 3. I touched one pin with ground and now it died :/Please replace the IC NCP5623 on FC No. 3. I touched one pin with ground and now it died :/Benedikt SchleusenerBenedikt Schleusenerhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/15NewDebugger 4 Sattelady2017-05-21T08:27:46ZBenedikt SchleusenerNewDebugger 4 SatteladyNew Debugger should have picoblade connectersNew Debugger should have picoblade connectersBenedikt SchleusenerBenedikt Schleusenerhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/16Strange behavior of uart (every second time sends only header).2017-05-21T08:27:46ZElias RoschStrange behavior of uart (every second time sends only header).@thorbjoern.joerger , @Martin.dold
I was debuggin in the lab today and managed to get the strange behavior fixed.
Unfortunately this is not a permanent solution as it is very dirty.
I started a new feature where the fix (one line) ...@thorbjoern.joerger , @Martin.dold
I was debuggin in the lab today and managed to get the strange behavior fixed.
Unfortunately this is not a permanent solution as it is very dirty.
I started a new feature where the fix (one line) is applied (Sorry Thor for opening a new feature, but the one we had was somehow completely rearranged and did not work at all, so i just added one line to the current develop-code).
feature is called feature/fix-strange-sproto-behavior:
commit contains updated submodule: bd8da16d · Very Dirty fix of sproto behavior.
commit of submodule/sproto: 88f2069a · Added (very) dirty fix to strange sending behavior. Need to figure out why this works!!!
There seems to be some timing problem (Sometimes only txStart is sent). When adding a tiny delay between txStart and txWrite everything works as it should.
No idea why this is --> I assume martin knows more.
I hope you can use this information somehow
Cheers.
https://gitlab.syscop.de/TOPCORE/mfw/-/issues/17Implement third PPS state2017-05-21T08:27:46ZThorbjörn JörgerImplement third PPS stateWhere PPS is generated by the controller itself. Preparation for switch from Systickhandler to PPS timing.Where PPS is generated by the controller itself. Preparation for switch from Systickhandler to PPS timing.https://gitlab.syscop.de/TOPCORE/mfw/-/issues/18Change betCOM basic_conf from frequency to intervall2017-05-21T08:27:46ZThorbjörn JörgerChange betCOM basic_conf from frequency to intervallhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/20Replace all ROM_* function calls by MAP_* functions calls2017-05-21T08:27:46ZThorbjörn JörgerReplace all ROM_* function calls by MAP_* functions callsProcessor specific defines will then select the ROM function call if it is available and otherwise default to the normal library call.Processor specific defines will then select the ROM function call if it is available and otherwise default to the normal library call.Elias RoschElias Roschhttps://gitlab.syscop.de/TOPCORE/mfw/-/issues/21Restructure firmware message in betCOM and FC2017-05-21T08:27:46ZThorbjörn JörgerRestructure firmware message in betCOM and FCOnly message in betconf should be {FC/ARM...}_firmware<br>
Each firmware message consistst of:<br>
* MFW_version
* protobuf_version
* nanopb_version
* betcom_version
* ...Only message in betconf should be {FC/ARM...}_firmware<br>
Each firmware message consistst of:<br>
* MFW_version
* protobuf_version
* nanopb_version
* betcom_version
* ...Thorbjörn JörgerThorbjörn Jörger2016-08-08https://gitlab.syscop.de/TOPCORE/mfw/-/issues/22TM4C123x simply doesn't want to talk2017-05-21T08:27:46ZElias RoschTM4C123x simply doesn't want to talk@evileli , @julian.reimer : Today still trying to get the hal_uart_api to run on TM4C123x arquiteqture. For now we are trying to get some bits onto the TX-line.
Still no success. Just pure emptiness.
Last commit: 5e563259 · Solved ...@evileli , @julian.reimer : Today still trying to get the hal_uart_api to run on TM4C123x arquiteqture. For now we are trying to get some bits onto the TX-line.
Still no success. Just pure emptiness.
Last commit: 5e563259 · Solved build issue w. satellady project. --> Test code: test-app-satellady
What we know so far:
- We think the issue is located somewhere at the configuration for the DMA. The DMA-interrupt fires once at initialization of UART-module and from there on there is not a single interrupt anymore. Something seems not to be compatible with the code for TM4C129x. We searched in the code for some obvious incompatibilities but did not find anything until now.
Ideas? @thorbjoern.joerger , @Martin.dold Elias RoschElias Rosch