Purple status pixel during main running

[tannewt]

Its configured to be green while main runs. See main.c and supervisor/shared/ for related code.

[sommersoft]

Quick debug log, in case anyone can readily explain why the below is happening. As this shows, we're ending up at reset_mp, which sets the pixel to 0x8f008f (purple).

<function>      (<caller>)    <variable>: <variable value>; <variable>: <variable value>
--------------------------------------------------------------------------------------------
new_status_color(reset_mp):: current_status_color: could not evaluate; rgb: 9371791
new_status_color(main):: current_status_color: could not evaluate; rgb: 16
new_status_color(reset_mp):: current_status_color: could not evaluate; rgb: 9371791
new_status_color(start_mp):: current_status_color: could not evaluate; rgb: 4096
new_status_color(reset_mp):: current_status_color: could not evaluate; rgb: 9371791

Back to the salt mines...

EDIT:
This was on a Trinket, using my local 3.0 alpha 1....I need to update, but waiting on pending PRs. Windows makes things, let's say, troublesome. 😟

[sommersoft]

Intermediate update. After expanding my breakpoints, seems at this point, that tick_rgb_status_animation either never calls new_status_color to update the color, or something during those calls is failing/causing purple. Atmel Studio continues to be an obstruction on retrieving some values (unless this is just the nature of hardware debug that I don't know; could also be since I'm running off of the ELF object).

Getting closer (I hope). Time to go do some adulting... 😒

new_status_color(reset_mp):: rgb: 9371791
new_status_color(main):: rgb: 16
new_status_color(reset_mp):: rgb: 9371791
start_mp(main):: result.return_code: 123995; result.exception_type: 0x0; result.exception_line: 1; animation.exception_color: 100352; animation.ok: true
new_status_color(start_mp):: rgb: 4096
new_status_color(reset_mp):: rgb: 9371791
prep_rgb_status_animation(start_mp):: safe_mode: NO_SAFE_MODE; status.ok: 236; result.return_code: 0; status.exception_color: 180520
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484
....tick_rgb_status_animation just continues to repeat....

[sommersoft]

One last update for tonight. Still expanding the breakpoints, but not exactly closer. Trying to rectify why tick_rgb_status_animation never calls new_status_color, like its supposed to. Two things I'm focusing on are values for neopixel/apa102_in_use (can't get trace info on it), and the reset_pin function which doesn't seem to be firing. Those two together are logical reasons why common_hal_xxxx_write is not firing during new_status_color.

Only other explanation I can see would be a larger failure of MICROPY_HW_NEOPIXEL/APA102 definitions not evaluating properly in multiple places. I've checked the spelling like 15 times; all seems good.

More after work tomorrow...

Current Breakpoint List:

Latest Debug Log:

rgb_led_status_init(main)
reset_status_led(reset_mp)
new_status_color(reset_mp):: rgb: 9371791
new_status_color(main):: rgb: 16
reset_status_led(reset_mp)
new_status_color(reset_mp):: rgb: 9371791
start_mp(main):: result.return_code: 123995; result.exception_type: 0x0; result.exception_line: 1; animation.exception_color: 100352; animation.ok: true
new_status_color(start_mp):: rgb: 4096
reset_status_led(reset_mp)
new_status_color(reset_mp):: rgb: 9371791
reset_status_led(start_mp)
prep_rgb_status_animation(start_mp):: safe_mode: NO_SAFE_MODE; status.ok: 236; result.return_code: 1024; status.exception_color: 180520
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484
tick_rgb_status_animation(start_mp):: status.ok: 236; status.pattern_start: 180472; status.exception_color: 180520; status.safe_mode: 17; status.total_exception_cycle: 180484

[tannewt]

That purple color could be my fault... I may have added it during debugging. I did reshuffle the order of reset_mp calls which may have made this more obvious.

I vote you remove the purple line.

[sommersoft]

That purple color could be my fault... I may have added it during debugging.

It was actually in 2.x as well...so I don't think it was related. (It didn't "fix" the issue).

While looking back through the commit history, I came across 942b7ff from @siddacious, fixing #514. In his comments he mentioned that he got "statusing". After talking to him on discord tonight, I decided to scrap my local stuff and update my local working tree (since I was on 3.0alpha1).

No more Purple Pixel. I ran through all of the statuses (minus SAFE) and raised the errors; each color displays and matches rgb_led_colors.h. I know siddacious' commit pre-dates when this issue was created, but I don't see anything else that could've fixed it.

This is all on a Trinket. Can test a Feather M0 tomorrow. CPX and Itsy will be in the mail soon.

Can anyone else confirm that the current master does not have this issue?

[siddacious]

No dice for me; just pulled an built on my trinket and I still get a purple dotstar while it's running

[sommersoft]

Odd. I even checked to make sure I didn't have leftovers from previous work... Guess I'll have to check again.

[sommersoft]

@siddacious, I would have tested this before commenting, but didn't think about it until this morning on the way to work.

When you built the firmware, did you use DEBUG=1? It's the only differentiation I can readily think of (I built with debug on). Seems like a longshot, but figured I'd ask...

[siddacious]

I didn't build with debug on.

[ladyada]

fyi purple is the default pixel color out of bootloader so it may mean your pixel isnt working at all

[sommersoft]

@siddacious thanks. I'll test later without debug. I'm not too hopeful, but the flags might be optimizing something out. ???

@ladyada I was working my way through this with that in mind. I was beginning to think that the checks to see if the pins are in use, we're actually blocking the updates after the initial purple. We'll see...