Repository navigation
Button lights test build - #2
Closed
steponme82 wants to merge 9 commits into
Closed
steponme82 wants to merge 9 commits into
steponme82 wants to merge 9 commits into
Conversation
isod89#8. LED_PROBE 1 (off by default) builds a firmware that plays no sound and makes one pin at a time blink at 2 Hz while its name is on the screen. The knob steps through the 50 pins, the right footswitch marks a pin, the left one redraws the screen. The screen, knob, I2S, amp enable and MASTER pins are never driven; the buttons are (on the FM-1, PH6 and PH9 are LED lines). A pin that resets the chip is skipped after the reset. USB stays up, so the web installer is the way back. tests/lpsim.c runs it against fake GPIO registers and checks that only the pin on screen ever changes, that each goes back exactly as it was, and that every line fits the screen. Added to tests/run_tests.sh. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
isod89#8. The light finder showed that no single pin lights anything: the lights sit behind one 74HC595. isod89 read its routine in BlackBox_020 (PocketX_016 has the same): DS = PC8, SHCP = PC5, STCP = PC6, OE not driven, PC7 kept high. A byte goes out MSB first, a few us per step. firmware/px_leds.h is that driver: leds_init (the three pins become outputs without pulls, SHCP 1, STCP 0, DS 0, then 0 is shifted out, as stock) and leds_write. Main loop only: every edge is a read-modify-write of PORTC OUT. LED_PROBE 1 now builds the LED map instead of the light finder (git history has the old one): no sound, the knob steps through ALL 8 BITS and BIT 0..7, which blink at 2 Hz between their byte and 0, so the light that changes is theirs whatever its polarity. Pressing the button whose light blinks writes it into a table on screen (FX, MOD, AMP, CAB, DLY, REV, HOME, PUSH, either footswitch); the same button again clears it. USB stays up. tests/lpsim.c now models the 595 from its data sheet and checks, on every pass, that only PC5/PC6/PC8 change, that each shift clock edge and the latch have a wait before them with the latch low while shifting, and that the latched byte is the one on screen (MSB first). Ten deliberate driver mistakes (LSB first, a missing wait, the latch left high, DS after the clock, a wrong pin, pulls left on, no blink...) all fail it. The normal build is unchanged: px_leds.h is only included with LED_PROBE 1. Not run on a pedal yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
isod89#8. The LED map drove the 74HC595 as isod89 read it in the stock firmware (data PC8, clock PC5, latch PC6) and nothing lit on a BlackBox, not even all 8 bits blinking. LED_PROBE 1 now builds the LED hunt instead (git history has the map), which tests what that reading could be missing. The knob steps through: - PIN CHECK: PC5, PC6 and PC8 driven to 1 and 0 and read back, then inputs with a pull-up and a pull-down: DRIVES OK, FREE for a pin wired only to a 595 input, STUCK / HELD for one something else holds. - ROLES 1 to 6: the six ways to give data, clock and latch to the three pins (1 is isod89's), all 8 bits blinking. - LED LINE 1 to 47: one more pin at a time blinks while the 595 blinks FF / 00 at half the rate, so all four mixes come once a second. On the FM-1 the 595 only selects a column and an LED needs its LED line driven too; a missing enable would show the same way. The pins never driven are the light finder's list (screen, knob, I2S, amp enable, MASTER, analog keys, flash) plus PC5/6/8. CAB, DLY or REV marks a test on screen. USB stays up. px_leds.h: leds_shift / leds_setup take the pins as parameters (the hunt tries other roles); leds_init / leds_write are the driver as before. tests/lpsim.c models pads with pulls and outside holds, and the 595 as isod89 read it. It checks the driver alone (each byte MSB first, no pulls left), the pin check on free and on held pins, the timing rules with isod89's roles, all four mixes on every line, that only PC5/6/8 and the line on screen ever change and are given back, and the marks. 13 of 14 deliberate mistakes fail it; the 14th (a pull-down left by the pin check) is cleared by the setup that follows. The normal build is unchanged. Not run on a pedal yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
steponme82
changed the title
isod89#8. The first LED hunt lit nothing on a BlackBox: no role swap, none of the 47 LED lines on ports A, B, C and H. Its pin check read PC5, PC6 and PC8 as STUCK AT 0, FREE. FREE (a pull-up reads 1, a pull-down 0) is what a 595 input looks like; STUCK AT 0 is not a finding, the AC79 SDK's gpio_read is valid only while the pin is an input. The six effect buttons light on the stock firmware, as isod89's six light bits say, so the byte layout fits and the missing piece is likely power. Since v33 OpenPocket leaves the supplies as the boot loader sets them. BlackBox_020's power init sets P3_ANA_CON5 to 0x74 (docs/AUDIO-SDK.md v30): VDDIOM 4, the I/O supply at 3.2 V (2.8 V + 0.1 V a level, AC79 SDK power_interface.h). After a power cycle it is whatever the boot loader leaves; the 595 and the lights may need the stock level. The knob now starts on POWER AS FOUND (CON5 and the voltage as found, after a power-on or kept from before a restart, all 8 bits blinking), then STOCK POWER (CON5 = 0x74, written once, kept until power-off, all 8 bits blinking), then the six roles and the 47 lines at that voltage. The pin check is gone. Any analog key reading below 900 marks, so a moved supply cannot break the marks. tests/lpsim.c fakes the always-on domain: POWER AS FOUND writes nothing, STOCK POWER writes CON5 = 0x74 once and no other power register, both blink, a restart shows the kept level. 14 of 14 deliberate mistakes fail it. The normal build is unchanged. Not run on a pedal yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
isod89#8. The LED hunt lit nothing with the stock I/O supply either: the pedal starts at 3.5 V (CON5 level 7), 3.2 V (stock's 0x74) changed nothing, and neither did the six roles or the 47 LED lines at it. Every probe so far ran without the normal start: no I2S (MCLK out on PA4), no amp enable (PA9, never driven by any probe), no audio interrupts. If the lights share a supply or an enable with that side, they were off in every test. LED_BLINK 1 (off by default) builds the normal firmware, sound and all, plus px_leds.h: leds_init after audio_start, then all 8 bits FF / 00 at 2 Hz from the main loop. The boot screen says LED TEST. Normal builds are unchanged (px_leds.h is not included). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…blinking), LED_PROBE 0 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
isod89#8. Every probe lit nothing: the LED map, the LED hunt (role swaps, 47 extra lines, the stock I/O supply) and the normal firmware with the 595 blinking. Read with JieLi's objdump, BlackBox_016, _020 and _021 drive the lights the same way: the 595 on PC8 / PC5 / PC6 as isod89 read it, and PC7. The 595 init sets PC7 high with the three pins and loads the first byte; then PC7 goes low and stays low: in 016 / 020 as the first step of the screen init, in 021 right after that first byte (and 021 sets it high again on its way off). The stock screen runs with PC7 low, so it is not a screen line: it is the lights' enable, low = on, most likely the 595's OE. OpenPocket has always held it high, and so did every probe. px_leds.h: leds_init now loads the stock's all-off byte (FF on the wire: the stock sends its byte inverted and writes logical 0 at power-off) with PC7 high, then drives PC7 low. leds_enable(on) is the switch. LED_PROBE 1 builds the LED map again (git history), with the lights enabled: ALL 8 BITS, then BIT 0..7, each blinking, and the button table. The hunt is in git history. tests/lpsim.c models PC7 as the 595's output enable: PC7 goes low once, after the all-off byte is latched, and ends an output; the driver alone (from pins with pulls, PC7 an input), bytes MSB first, and the map's checks as before. 11 of 11 deliberate mistakes fail it (enable never set, set before the byte, inverted, PC7 left an input, wrong off byte, LSB first, a missing wait...). openpocket.c: the comments that called PC7 a screen line now say what it is. The normal build still holds it high (lights off) and is unchanged. Not run on a pedal with PC7 low yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…OME in the tuner) isod89#8. With PC7 low after the first byte the LED map lit every button on a BlackBox, and the map is the panel's order: bit 0 HOME, 1 FX, 2 AMP, 3 MOD, 4 DLY, 5 REV, 6 CAB, 7 none. firmware/px_lights.h decides the lights once per main-loop pass from the preset: AMP, MOD, DLY, REV and CAB lit while their block is on, FX while any block of the FX button's group is on (drive, SFX, synth, pitch, comp, gate, EQ: ui.h's UI_FXB, now shared with ui_fx_cycle), HOME blinking at 2 Hz while the tuner is open. On the wire a 0 lights, so the byte goes out inverted, and only when it changes (as the stock firmware). The normal firmware calls leds_init after audio_start (all off loaded, then PC7 low) and lights_update in the main loop; the update screen turns them off (px_usb.h PX_LIGHTS_OFF, from ota_show). Not in this change: a setting to switch the lights off. It belongs with the settings store isod89#10 adds. LED_BLINK (the test switch) is gone; LED_PROBE 1 still builds the LED map. tests/lightsim.c: every block alone lights its own button, all on lights the six and not HOME, HOME blinks at 2 Hz in the tuner only, bit 7 never lit, nothing written when nothing changes, lights_off, only PC5..PC8 touched. Its expected bits are the LED map's, written out again; 8 of 8 deliberate mistakes fail it. In run_tests.sh the step keeps the test's exit code (a pipe into tail would hide it). Not run on a pedal yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Only here to make GitHub build test firmware for isod89#8. Do not merge here: once it works on the pedal, the branch
leds-595goes to isod89 as a pull request.The build now is the normal firmware with the button lights working: AMP, MOD, DLY, REV and CAB light while their block is on, FX while any block of the FX group is on, HOME blinks in the tuner. The lights need PC7 low after the first byte (found with JieLi's objdump on the stock firmware), and the LED map read on a BlackBox gives the bits: 0 HOME, 1 FX, 2 AMP, 3 MOD, 4 DLY, 5 REV, 6 CAB.
The build's files (
BlackBox_936.fwscand the others) are under Artifacts on the run's page.🤖 Generated with Claude Code