From 780d7851a7f90a897bbe9d1a5ee8f0b57a5bf3a0 Mon Sep 17 00:00:00 2001 From: Castor Gemini Date: Thu, 21 Aug 2025 02:28:09 -0500 Subject: [PATCH 1/7] fix: Make OpenOCD reboot script more robust - Use 'reset halt' to reliably gain control of the target. - Add explicit timings to the reset signal configuration to prevent timeouts and improve stability. --- openocd-reboot.cfg | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/openocd-reboot.cfg b/openocd-reboot.cfg index cbb1691..1ac14f5 100644 --- a/openocd-reboot.cfg +++ b/openocd-reboot.cfg @@ -1,4 +1,4 @@ -# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board +# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v2) # ---------------------------------------------------------------- # 1. Adapter and Board Configuration @@ -15,40 +15,38 @@ ftdi layout_signal nTRST -data 0x0100 -oe 0x0100 # ---------------------------------------------------------------- transport select jtag set _CHIPNAME riscv -jtag newtap $_CHIPNAME cpu -irlen 5 ;# P550 has an IR length of 5 +jtag newtap $_CHIPNAME cpu -irlen 5 -# Define the 4 P550 cores target create riscv.cpu0 riscv -chain-position $_CHIPNAME.cpu -coreid 0 target create riscv.cpu1 riscv -chain-position $_CHIPNAME.cpu -coreid 1 target create riscv.cpu2 riscv -chain-position $_CHIPNAME.cpu -coreid 2 target create riscv.cpu3 riscv -chain-position $_CHIPNAME.cpu -coreid 3 - -# Group the cores for simultaneous operations like halt/resume target smp riscv.cpu0 riscv.cpu1 riscv.cpu2 riscv.cpu3 # ---------------------------------------------------------------- # 3. Reset Configuration and Execution # ---------------------------------------------------------------- -# This is the key command. It tells OpenOCD that a "reset" should -# assert (pull low) the nSRST signal. -# srst_only: Asserts only nSRST, not nTRST (JTAG reset). -# srst_pulls_trst: Informs OpenOCD that the board hardware ties nSRST and nTRST together. -reset_config srst_only srst_pulls_trst +# Configure the reset signal. +# srst_only: Asserts only nSRST. +# srst_pulls_trst: Informs OpenOCD that nSRST and nTRST are connected. +# srst_assert_width: Hold the reset signal for 100ms (a good, long pulse). +# srst_deassert_delay: Wait 100ms after releasing reset for the system to stabilize. +reset_config srst_only srst_pulls_trst srst_assert_width 100 srst_deassert_delay 100 # Initialize OpenOCD and connect to the target init -# Halt the cores to gain control -halt +# --- The Improved Reboot Sequence --- +# This is the most reliable way to gain control and issue a reset. +# 'reset halt' asserts the reset line, then immediately halts the cores +# as they come out of reset, before they can execute any code. +echo "!!! Issuing reset halt to gain control..." +reset halt -# This command now triggers the nSRST signal as configured above. -# It will pulse the reset line, causing a full hardware reboot. -echo "!!! Pulsing system reset (nSRST) to reboot the board..." -reset - -# Optional: If you want the board to start running immediately after reboot -# resume +# Now that the system is halted and stable, we can let it run. +echo "!!! Resuming execution to complete the reboot..." +resume # Exit OpenOCD -shutdown +shutdown \ No newline at end of file From 7ea9888a5df3a38c42f8f0742b20c6e54816e5b7 Mon Sep 17 00:00:00 2001 From: Castor Gemini Date: Thu, 21 Aug 2025 02:29:13 -0500 Subject: [PATCH 2/7] fix: Improve OpenOCD stability for P550 reboot - Add explicit 'adapter speed' to fix low-speed warning. - Separate nSRST and nTRST handling in 'reset_config' to prevent JTAG communication timeouts ('mpsse_flush' errors). --- openocd-reboot.cfg | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/openocd-reboot.cfg b/openocd-reboot.cfg index 1ac14f5..85233e7 100644 --- a/openocd-reboot.cfg +++ b/openocd-reboot.cfg @@ -1,4 +1,4 @@ -# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v2) +# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v3) # ---------------------------------------------------------------- # 1. Adapter and Board Configuration @@ -6,6 +6,12 @@ adapter driver ftdi ftdi channel 2 ftdi vid_pid 0x0403 0x6011 + +# NEW: Set the JTAG clock speed. +# Start with a conservative but reasonable speed. 1000 kHz = 1 MHz. +# If this works, you can try increasing it to 5000 or 10000 for faster performance. +adapter speed 1000 + ftdi layout_init 0x0808 0x0a1b ftdi layout_signal nSRST -oe 0x0200 ftdi layout_signal nTRST -data 0x0100 -oe 0x0100 @@ -27,18 +33,16 @@ target smp riscv.cpu0 riscv.cpu1 riscv.cpu2 riscv.cpu3 # 3. Reset Configuration and Execution # ---------------------------------------------------------------- -# Configure the reset signal. -# srst_only: Asserts only nSRST. -# srst_pulls_trst: Informs OpenOCD that nSRST and nTRST are connected. -# srst_assert_width: Hold the reset signal for 100ms (a good, long pulse). -# srst_deassert_delay: Wait 100ms after releasing reset for the system to stabilize. -reset_config srst_only srst_pulls_trst srst_assert_width 100 srst_deassert_delay 100 +# MODIFIED: Changed the reset configuration. +# By removing 'srst_pulls_trst', we are telling OpenOCD to handle the +# JTAG reset (nTRST) and the system reset (nSRST) as separate signals. +# This is often more reliable on complex SoCs. +reset_config srst_only srst_assert_width 100 srst_deassert_delay 100 # Initialize OpenOCD and connect to the target init # --- The Improved Reboot Sequence --- -# This is the most reliable way to gain control and issue a reset. # 'reset halt' asserts the reset line, then immediately halts the cores # as they come out of reset, before they can execute any code. echo "!!! Issuing reset halt to gain control..." @@ -49,4 +53,4 @@ echo "!!! Resuming execution to complete the reboot..." resume # Exit OpenOCD -shutdown \ No newline at end of file +shutdown From dffde739652f562d92ab5cb29c6064c5ff8ce275 Mon Sep 17 00:00:00 2001 From: Castor Gemini Date: Thu, 21 Aug 2025 02:31:35 -0500 Subject: [PATCH 3/7] fix: Revert to manual reset for OpenOCD 0.12.0 compatibility - The 'srst_assert_width' flag is not supported in 0.12.0. - Revert to using manual 'ftdi_set_signal' commands to pulse the nSRST line, which is the correct method for older OpenOCD versions. - This should fix both the syntax error and the 'mpsse_flush' timeouts. --- openocd-reboot.cfg | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/openocd-reboot.cfg b/openocd-reboot.cfg index 85233e7..80cf412 100644 --- a/openocd-reboot.cfg +++ b/openocd-reboot.cfg @@ -1,4 +1,5 @@ -# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v3) +# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v4) +# Compatible with OpenOCD 0.12.0 # ---------------------------------------------------------------- # 1. Adapter and Board Configuration @@ -6,10 +7,6 @@ adapter driver ftdi ftdi channel 2 ftdi vid_pid 0x0403 0x6011 - -# NEW: Set the JTAG clock speed. -# Start with a conservative but reasonable speed. 1000 kHz = 1 MHz. -# If this works, you can try increasing it to 5000 or 10000 for faster performance. adapter speed 1000 ftdi layout_init 0x0808 0x0a1b @@ -33,24 +30,32 @@ target smp riscv.cpu0 riscv.cpu1 riscv.cpu2 riscv.cpu3 # 3. Reset Configuration and Execution # ---------------------------------------------------------------- -# MODIFIED: Changed the reset configuration. -# By removing 'srst_pulls_trst', we are telling OpenOCD to handle the -# JTAG reset (nTRST) and the system reset (nSRST) as separate signals. -# This is often more reliable on complex SoCs. -reset_config srst_only srst_assert_width 100 srst_deassert_delay 100 +# Configure the reset type, but without the unsupported timing flags. +# We will control the pulse manually. +reset_config srst_only # Initialize OpenOCD and connect to the target init -# --- The Improved Reboot Sequence --- -# 'reset halt' asserts the reset line, then immediately halts the cores -# as they come out of reset, before they can execute any code. -echo "!!! Issuing reset halt to gain control..." -reset halt +# --- Manual Reboot Sequence for OpenOCD 0.12.0 --- +echo "!!! Manually asserting system reset (nSRST)..." +# Pull nSRST low (active low, so '0' asserts it) +ftdi_set_signal nSRST 0 +# Hold the reset for 100ms to ensure the board registers it +sleep 100 -# Now that the system is halted and stable, we can let it run. -echo "!!! Resuming execution to complete the reboot..." +echo "!!! De-asserting system reset and attempting to halt..." +# Release nSRST (set it back to high-impedance/inactive) +ftdi_set_signal nSRST 1 +# Wait a moment for the board to start coming out of reset +sleep 100 + +# Immediately after releasing reset, halt the cores. +# This is the critical step to catch them before they boot the OS. +halt + +echo "!!! System halted successfully. Resuming execution to boot..." resume # Exit OpenOCD -shutdown +shutdown \ No newline at end of file From 6a23954f1fa0cbca7d386ab0819c8af2688e1f1b Mon Sep 17 00:00:00 2001 From: Castor Gemini Date: Thu, 21 Aug 2025 02:34:09 -0500 Subject: [PATCH 4/7] fix: Correct OpenOCD reset config to prevent libusb crash - The root cause of the 'mpsse_flush' and libusb errors was an incorrect reset configuration. - Use 'reset_config srst_only separate' to correctly inform OpenOCD that the JTAG (nTRST) and system (nSRST) resets are independent. - This allows the 'init' command to reliably establish JTAG communication before a system reset is issued. --- openocd-reboot.cfg | 40 +++++++++++++++------------------------- 1 file changed, 15 insertions(+), 25 deletions(-) diff --git a/openocd-reboot.cfg b/openocd-reboot.cfg index 80cf412..bb70ea8 100644 --- a/openocd-reboot.cfg +++ b/openocd-reboot.cfg @@ -1,5 +1,5 @@ -# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v4) -# Compatible with OpenOCD 0.12.0 +# OpenOCD Configuration to REBOOT a SiFive HiFive Pro P550 Board (v5) +# Correctly handles separate JTAG and System resets to prevent timeouts. # ---------------------------------------------------------------- # 1. Adapter and Board Configuration @@ -30,32 +30,22 @@ target smp riscv.cpu0 riscv.cpu1 riscv.cpu2 riscv.cpu3 # 3. Reset Configuration and Execution # ---------------------------------------------------------------- -# Configure the reset type, but without the unsupported timing flags. -# We will control the pulse manually. -reset_config srst_only +# CRITICAL: Configure the reset strategy. +# 'srst_only': The 'reset' command will only pulse the nSRST line. +# 'separate': Tells OpenOCD that nSRST and nTRST are independent signals. +# This allows the 'init' command to correctly reset the JTAG TAP +# (using nTRST) before trying to communicate with it. +reset_config srst_only separate -# Initialize OpenOCD and connect to the target +# Initialize OpenOCD. This will now correctly reset the JTAG chain. init -# --- Manual Reboot Sequence for OpenOCD 0.12.0 --- -echo "!!! Manually asserting system reset (nSRST)..." -# Pull nSRST low (active low, so '0' asserts it) -ftdi_set_signal nSRST 0 -# Hold the reset for 100ms to ensure the board registers it -sleep 100 +# Issue the system reset. Because of the config above, this will now +# cleanly pulse the nSRST line, causing a hardware reboot. +echo "!!! Issuing system reset to reboot the board..." +reset -echo "!!! De-asserting system reset and attempting to halt..." -# Release nSRST (set it back to high-impedance/inactive) -ftdi_set_signal nSRST 1 -# Wait a moment for the board to start coming out of reset -sleep 100 - -# Immediately after releasing reset, halt the cores. -# This is the critical step to catch them before they boot the OS. -halt - -echo "!!! System halted successfully. Resuming execution to boot..." -resume +echo "!!! Board has been reset and should be rebooting now." # Exit OpenOCD -shutdown \ No newline at end of file +shutdown From d6e439de5b36e5e22f1715de2395017f34d1e732 Mon Sep 17 00:00:00 2001 From: Jeff Carr Date: Thu, 21 Aug 2025 12:29:59 -0500 Subject: [PATCH 5/7] stuff --- Makefile | 6 +++++- reset_sifive_usb.sh | 0 2 files changed, 5 insertions(+), 1 deletion(-) mode change 100644 => 100755 reset_sifive_usb.sh diff --git a/Makefile b/Makefile index fa35ebe..89297a6 100644 --- a/Makefile +++ b/Makefile @@ -15,7 +15,11 @@ goimports: test: # GO111MODULE=off go run format_rich_log.go log/2025-08-20-rich.text - GO111MODULE=off go run format_rich_log.go log/2025-08-20-full.text + # GO111MODULE=off go run format_rich_log.go log/2025-08-20-full.text + GO111MODULE=off go run format_rich_log.go log/2025-08-20-final.text gemini-config: cp ~/.gemini/GEMINI.md . + +gemini-go: + ~/go/bin/gemini playback diff --git a/reset_sifive_usb.sh b/reset_sifive_usb.sh old mode 100644 new mode 100755 From 7e69b1d83df466017734b61abf1a00405fe36fd4 Mon Sep 17 00:00:00 2001 From: Castor Gemini Date: Thu, 21 Aug 2025 13:28:53 -0500 Subject: [PATCH 6/7] docs: Add BACnet conversation log - Create a new log file and content files detailing the discussion about BACnet and Modbus protocols. --- log/BACnet.text | 12 ++++++++++++ log/content/bacnet_a1.content | 20 ++++++++++++++++++++ log/content/bacnet_q1.content | 1 + 3 files changed, 33 insertions(+) create mode 100644 log/BACnet.text create mode 100644 log/content/bacnet_a1.content create mode 100644 log/content/bacnet_q1.content diff --git a/log/BACnet.text b/log/BACnet.text new file mode 100644 index 0000000..e637454 --- /dev/null +++ b/log/BACnet.text @@ -0,0 +1,12 @@ +uuid: "bacnet-log-01" +version: "v0.0.3 go.wit.com/lib/protobuf/chatpb" +Chats: { + from: USER + ctime: { seconds: 1724166000 } + content_file: "content/bacnet_q1.content" +} +Chats: { + from: GEMINI + ctime: { seconds: 1724166060 } + content_file: "content/bacnet_a1.content" +} diff --git a/log/content/bacnet_a1.content b/log/content/bacnet_a1.content new file mode 100644 index 0000000..65567ad --- /dev/null +++ b/log/content/bacnet_a1.content @@ -0,0 +1,20 @@ +You've described the situation perfectly. The protocol you're thinking of for HVAC and industrial controls is almost certainly **BACnet** or **Modbus**. + +Both are foundational protocols in building automation and industrial control, and they share the same conceptual space as CAN bus does for vehicles. + +First, to clarify your other point: **CAN bus** (Controller Area Network) is exactly what it's called. It's a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer. + +Here is a breakdown of the industrial/HVAC equivalents: + +| Protocol | Primary Use | Physical Layer | Key Concept (How it's like CAN bus) | +| :--- | :--- | :--- | :--- | +| **BACnet** | **Modern HVAC & Building Automation** | Runs on many layers, but commonly **RS-485** (a 2-wire bus, like CAN) or Ethernet (BACnet/IP). | This is the dominant, open standard for complex building control (chillers, air handlers, lighting, security). It allows devices from different manufacturers to interoperate in a single system. | +| **Modbus** | **Industrial Controls & Simple HVAC** | Also commonly runs on **RS-485** (Modbus RTU) or Ethernet (Modbus TCP). | This is the de facto standard for industrial devices. It's simpler than BACnet and is a master-slave protocol (one device polls, others respond), but it serves the same purpose of connecting sensors, drives, and controllers on a shared network. | +| **LonWorks** | Building, Home, and Industrial Automation | Twisted Pair (Free Topology) | A strong competitor to BACnet. It's a peer-to-peer protocol, which is conceptually very similar to CAN's multi-master design, where any device can initiate communication. | + +### Which one are you thinking of? + +* If you're thinking about a modern, large commercial building's entire automation system, the answer is **BACnet**. +* If you're thinking about the most common, simple, and widespread protocol for connecting industrial sensors, VFDs (Variable Frequency Drives), and basic controllers, the answer is **Modbus**. + +Given the direct comparison to CAN bus as a system-wide network, **BACnet** is the most likely protocol you're trying to remember for the HVAC world. \ No newline at end of file diff --git a/log/content/bacnet_q1.content b/log/content/bacnet_q1.content new file mode 100644 index 0000000..7f81442 --- /dev/null +++ b/log/content/bacnet_q1.content @@ -0,0 +1 @@ +there is a protocol used in HVAC and instustrial controls but I forgot what it is called. It is similar in concept to what the automotive industry uses called "canBUS" or "CAN BUS" (I'm not sure what that is called either). \ No newline at end of file From 2c7099c1cc623fd7a32e51261a9088721fc0a7d2 Mon Sep 17 00:00:00 2001 From: Jeff Carr Date: Thu, 21 Aug 2025 14:13:19 -0500 Subject: [PATCH 7/7] changed field names --- Makefile | 4 ++++ log/BACnet.text | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 89297a6..10df64d 100644 --- a/Makefile +++ b/Makefile @@ -23,3 +23,7 @@ gemini-config: gemini-go: ~/go/bin/gemini playback + +add: + ~/go/bin/gemini --add log/BACnet.text + ls -lt ~/.config/gemini/ diff --git a/log/BACnet.text b/log/BACnet.text index e637454..986bc92 100644 --- a/log/BACnet.text +++ b/log/BACnet.text @@ -3,10 +3,10 @@ version: "v0.0.3 go.wit.com/lib/protobuf/chatpb" Chats: { from: USER ctime: { seconds: 1724166000 } - content_file: "content/bacnet_q1.content" + ContentFile: "content/bacnet_q1.content" } Chats: { from: GEMINI ctime: { seconds: 1724166060 } - content_file: "content/bacnet_a1.content" + ContentFile: "content/bacnet_a1.content" }