[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

I've helped you quite a bit (for free, for boards you're selling), and I will keep an eye out for this as well.

I will certainly not test for free and certainly not pay to test your boards with your hardware selection. I will test my boards for timing on various versions, like everyone else who has made new OTSM hardware or software configurations has done. It takes literally 2 minutes to flash a version and say what blinks. It takes hours to develop and debug the versions. Thanks for helping.

It is certainly true that for now 1.3-r2 is the most tested and proven version for basic TA otsm builds.

So, I am considering to make medium press to enter hidden modes but short press to cycle through them. This wouldn't be until after stabilizing present builds.

I don't like making too many UI changes, because possibilities are endless and I want to keep close to consistent. But med press back through all the hidden modes can be annoying if you want one quickly. I haven't even though yet about the details of how to do it. Doing it intelligently probably requires a significant change to the modegroup construction routine that went through a ton of optimization already. [edit: ok really it just requires reversing the hidden mode definitions in all the modegroup config files, doing it that way is an API change though from the perspective of imagined mod-ers with their own modegroups, so it should come with a new preproc define to enable it, more of an issue the later it's done].

I very much like this idea of not having to medium press four times before getting to the desired function! Hope it gets worked out.

@Lexel, if a board fails to opporate using v1.5, will it work if you erase and reflash with the same v1.5 firmware?

Yeah, it's something I like about Narsil, although I had it mind before I found it in Narsil. My problem with Narsil though is in strobes, battcheck etc, it takes a second to realize what mode you're in, and by then Narsil locks you out and you have to start over. 1.2 second control lockout in custom modes doesn't work unless you've memorized them and your brain isn't engaged in something else.

LightRider, he said he flashed it a few times if I read right. Rarely bad flashes happen, but it's rare.

What's clear, if the matrix is trustable (there wasn't a slight change in supply voltage, temp etc.. unlikely, but just making the conditions clear) is there is a difference in hardware AND there is a difference in software. And so I will DEFINTELY look on my end.

What we don't know is is the software difference very small and the hardware difference between his hardware and mine very big, with small variations within his hardware, or are all the hardware differences very small, and the software difference is very big.

The only thing I know in software that can degrade the performance a bunch are pin states, but they're set the same. I'll double check that in the simulator. I'll do my part, but I only have one fully functional non-prototype OTSM board and I have to desolder it to test it. I generally test features on my proto board, and just flash new whole versions to the light once in awhile to make sure it works. And it does.

It's cake for lexel to flash out the otsm-debug values for both builds because building and flashing boards is what he does, and it would definitely help me out.

Ok, so lexel didn't say he flashed it multiple times, my mistake.

Anyway, I just ran otsm-debug tests on 1.5 on my light. Desoldered again just to test it.

At 4.2V I could get up 13 seconds of click time. Should be enough.

At 3.1 V I got somewhere between 6 and 7.

At 2.9V, I could get around 4s.

Now what this all proves is that a bit weaker cap should probably be ok. But what it also proves is, 1.5 works fine on good hardware.

So, the issue status is presently changed to WORSFORME.

Lexel if you want to try to reproduce it and/or provide otsm-debug tests to potentially shed some light on what's going on on your end, that's great. There's nothing more I can say from here since I cannot reproduce your issue.

I also took the chance to use a stopwatch this time with the high voltage tests. 12 seconds read dead on as 48 wakes. Seems fairly accurate.

A theory for lexel's issue.

It occurred to me while I was stuck in muggle mode while stress testing 1.4.1 (so far so good, no freeze bug yet) that there is a way lexel's issue can happen, and it has nothing do with which version of the software he flashed

The first time the light start, it has no saved data. It tries to read saved data (specifically last mode) and sees there isn't any and stores all the initialization values to eeprom. Writes to eeprom are slow, about 3ms per byte. So if power is interrupted during that first turn-on, some values may not get set, and you may get memory turned off. A reset (menu item 8) will fix it.

There is a change in the software (any version) that can probably prevent this. The data that's checked should be the last data saved, then it's a commit. It's not that way right now. Simple fix and I'll include it in future releases. Might even release a 1.4.2 with it, since 1.4.1 seems very stable (haven't tested 1.5 as thoroughly yet).

This issue is no different on new builds than old ones, and it's never struck me, but it could be what happened to Lexel.

UPDATE I did take down 1.5 and 1.6 because neither achieved their goals yet, there is a different bug somewhere (not sure when, maybe even after 1.6) and because 1.4.1 is now well tested and was targeted specifically as a bug fix release, being created actually after 1.5 for the purpose of backporting bug-fixes from 1.5

The muggle mode may be the issue as the drivers with v1.5 had only 3 modes

But still never had such a muggle mode isseu with v1.3

If in Narsil in modegroups the 1.2s are you too short you can change that, lockout in ramping is definately more save with 4x clicks

If you had three modes then that's clearly what it was. Would have helped to mention that.

Good info about changing the lockout in Narsil. I still don't like mode lockout, but that's me. 4x lockout is a different thing entirely.

This isn't a version issue.. It's just a data storage commit. The data that is used to check if data was stored should be the last data written. This "bug" goes all the way back to original bistro. Although the code is very different now, the order of those steps is the same still and actually I've very rarely had what I shrugged off as "bad flashes" too and never realized or cared until now what it might be. I just flashed again. And I guess most people did. Most people would have at least bothered to try a second time before coming and declaring it as a clearly a new problem in the new version, especially since it did work for one board. Taking the 1 extra minutes to try would have also provided that extra clue real quick.

So, we've probably tracked down a tiny bug from original bistro that never much bothered anyone. Still it's easy to fix, assuming I've found the only potential cause of it.

As for 1.5, I've pulled it, not because of this, but because 1.4.1 is now pretty tested and 1.5 offers no real advancement until switch bugs get worked out. I'm not re-posting 1.3

The same save call is used at other times and I’ll have to review if at those times it may be more critical still to save the mode first. Another solution is to use a different variable for the commit check, but that causes all kinds of new issues too. This might be something we just live with. It hasn’t really caused problems before to most people and is only relevant on first start. A reflash or reset fixes it.

I've had about zero time in the last week and won't likely have much for another week, but I think little by little I've made the e-switch bug become apparent. Flashy Mike was actually right I think about watchdog timer but I think for the wrong reason (not entirely sure). Watchdog timer certainly doesn't reset just because interrupts are disabled or are not implemented. That's only if WDE is set to 1. But if wdie is set to 1 without setting wde to 1, it's in a purely interrupt mode without reset, or it certainly is according to the manual and to anything you can read about it. And that must be true because I used interrupts that did not reset the watchdog and that fact is required to explain the later parts.

However after some sequence of events I believe that the watchdog reset was somehow arming and tripping. There were a few things I had not understood about the watchdog reset (because I never intended to use it) or might have understood that sooner.

A) The watchdog prescale register gets reset to 16ms. I guess that's obvious, it's a full hardware reset, but I hadn't considered it.

B) The wdrf (watchdog reset flag) gets set in mcusr and causes the watchdog to be automatically armed on next start.

Then since my watchdog interrupts don't reset the watchdog, it dies again in 16ms. Initially this seemed just like locking. After building a minimal test case that happened to get the light on faster, it istead made a low pwm strobe. Then when I clicked the switch, it would seem to react and light correctly briefly, on short press and for quite awhile after restarting from long press off. Well my switch interrupt resets the watchdog timeout too 1/4s on short press for 1/4 sleeps and to 9s on long press. So it temporarily extended the timer. the 9 seconds really confused me because it would step through some code with no branches and suddenly just strobe again (reseting prescale again upon restart).

So it all adds up now except for one thing. Why is it triggering in the first place? And do I care? I cannot find any answer for that. Presumably something is writing to wde but only very rarely. The chance of it happening does seem to depend on random code variations, things like the length of time that interrupts are disabled for example. There is absolutely nothing in the manual that says a truly empty interrupt is required in interrupt mode or that missing or delaying interrupts should arm the watchdog if wde wasn't already set (this happens in combined interrupt/reset mode but not interrupt-only mode).

I find it hard to believe I have some corrupt runaway pointer that finds its way all the way down to the watchdog register and doesn't clobber a whole ton of other stuff first, and I see no sign of it on the simulator.

Still I'm assuming that if I do one or a few things, reset the watchdog in the interrupt, or clear wdrf on start, or both, that the problem will go away or at worst become a very rare misread click.

I'll give a shot soon. Sure would like to know the root cause though.

For what it's worth the manual does instruct one to do these things, but it also says basically to protect from runaway pointers or brownout corruption. Could I be seeing brown out corruption? on the attiny85 switch light? How? Or on the low voltage OTSM mcu with BODS? It doesn't make sense.

At this point I don't think the hardware debugger will help. I don't think there's a way to get a stack dump just prior to a watchdog reset.

Flintrock, thanks much for documenting this stuff! It’s not only to our benefit now but also for those to come. :slight_smile:

Well sadly this watchdog stuff is written up a ton of places, but it's just always confusing. I've read all those places and if I was struggling with it, (I was) I wouldn't mind having one more experience yet to read. I didn't add anything that isn't known, just maybe known things that still weren't obvious to me.

Everyone’s experience, method and perspective is different. The same diversity can be found in the learner. Documentations like this help bring together the two that mesh. To some it will be a bore and to others a bookmark. :slight_smile:

So I found it, there was a very tiny race in how I setup the watchdog, and just in those latest e-switch versions, although I find that I'm not resetting the zero time well in the earlier versions too, so this should also improve click time stability. The race was almost impossible to hit normally but some loop phase maybe made it more likely.

Anyway, the e-switch bug seems gone, so have to package a new version, do a bit more testing on non-switch again maybe, or maybe just release it as beta for now so long as it works on Q8.

Posted version 1.7

1.7 Q8 e-switch build now working and tested (with indicator). It’s long-press off.
Presently comes on with battery connection.

(More Fet+1 drivers can now be easily configured).

Improved click-time stability (maybe, nothing noticeable)
Includes TA e-switch build with dividerless read and indicator (wired to pin 7). (untested)
Includes a build for the dividerless 15mm OTC board.
Double-click autoflash scripts. Linux Makefile.

Many code improvements (including some aimed at portability). See CHANGES.txt in download for more detailed changes.

Dual switch builds should work now, but only fully tested e-switch build is the Q8. A dual-clicky switch just kills power. Every build must work when power is restored clearly, the only question being what they do on power on and if they also handle timing of some kind on the clicky switch

The new autoflash scripts allow flashing just by double-clicking a hex file (assuming of course your usbasp is hooked up). You first need to associate the appropriate bat file included. To do that, right click on the one for your chip and run as administrator. It will associate itself as the default program for opening hex files. Then just double click a hex and it flashes.

You may want to edit the bat file for fuses you like, but the included ones should work with HD. Although actually I should double check the attiny13 fuses.

The Makefile also works in linux now, so there's auto-building and auto-flashing all around. For the linux Makefile, I just downloaded the toolchain from here:

https://www.arduino.cc/en/Main/Donate

And unzipped it into / without installing it.

There seems to be another toolchain package availabel from Atmel (probably the more normal one), and if you use that or even just a different version number, you'll need to edit the Makefile paths to point to it. I will probably update the Makefile to point to a more normal Atmel installation soon. That's just the first link I found for whatever reason. I don't usually compile in linux, but it did work.

Flintrock, I must apologize. All this time I have stayed away from hd as I assumed that it required otsm for each build. :person_facepalming: I guess it’s obvious that it’s not but it simply never clicked. Even while reading the words over a number of times I didn’t get it. So, ive has parts for otsm for a while but now that I know I don’t have to figure out the hardware, hopefully I can finally give it a try. It will help a lot if I can learn to use hd and your make files. It could save a lot of time!