Armaan Chowfin commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1094#note_144216 Hi Gedare I discovered a few more lm3s69xx uart problems- this time I was trying to get lm4f120 builds (testsuites/samples) to run on my tm4c123 target board, with picocom on host to display text. 1. _None of the samples (all use the simple console driver) could display text_. The simple console driver path does not initialize the uart port (enable, set baud). For VMs, qemu most probably does uart port initialization during machine init - `NEEDS_SIMPLE_CONSOLE` samples all work on the lm3s6965evb. 2. _ticker.exe exceeds tm4c123 memory limits in every configuration (1 task/4 task/simple console/legacy console)._ This was creating a double fault: `_Internal_error() -> printk() -> bus error at uart->fr during write_polled()` . (verified by reading BFSR and MMFAR regs, see https://interrupt.memfault.com/blog/cortex-m-hardfault-debug) I moved uart initialization code (uart_clock_enable, baudrate set) to `bsp_start_hook_1()`). This fixes the uart prints for all samples and double fault too. 3. The TM4C123 datasheet (https://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf, page \~650, 660) mentions a GPIOPCTL register `0x52C`) that needs to be configured to enable uart. The port register struct in rtems lm3s69xx does not track this, but the uart prints were fixed without adding pctl code. I'm not sure why this should happen... Should I create an issue in rtos/rtems for all the lm3s69xx fixes? I could have a larger MR in a day or so. Regarding the rtems-tools, it might be better to create a new issue in tools/. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1094#note_144216 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
