Pinecil v2 short detection at boot

[alextrical]

• Please check if the PR fulfills these requirements

• The changes have been tested locally
• There are no breaking changes

• What kind of change does this PR introduce?

Bug fix/Feature
If tip is shorted at boot, go into an infinite NOP loop to prevent the FW from running, with the intent to prevent the MOSFET from being damaged

• What is the current behavior?

If a T12 tip is inserted into the handle too deep, it will short out terminals A & B causing the MOSFET to burn out

• What is the new behavior (if this is a feature change)?
  If a short is detected between terminals A & B prevent the FW from running and causing damage to the Pinecil v2 Hardware

• Other information:
  *Short of Pinecil V2 performed with a 1A fast blow fuse, and a 5v PSU to minimize chances of damage to hardware while testing

[discip]

@alextrical
Is it possible to display a message / warning during the loop, or are we too early for that at this point?

[alextrical]

It looks like the main screen is loaded at the time the check is performed, so the screen is initiated. (It shows the iron icon and voltage) assuming there is a messaging system that can be called, then it would be possible to do. Though I'm still new to this project, I compiled it for the first time today, but will see if I can work something out from the notes tomorrow

[discip]

@alextrical
You would need to add something like this:

IronOS/Translations/translation_EN.json

Lines 30 to 32 in 990f42a

	"WarningThermalRunaway": {
	"message": "Thermal\nRunaway"
	},

e.g.:

        "WarningShortedTip": {
            "message": "Wrong\ntip!"
        },

Or even suggest the solution:

        "WarningShortedTip": {
            "message": "Please\nchange tip!"
        },

[alextrical]

Ideal example, will get that added into the PR tomorrow. That definitely helps clear up what happend to the end user, rather than just locking up

[discip]

I think you know that my example is just a snippet of what needs to be changed:
These lines need to be added to every single translation_xx.json and Translation.h would need to be adapted as well as translations_definitions.json.

Here is an example for what needs to be changed by reference to 'CJCCalibrationDone'.

Pay attention to the order of the items, which must match in all affected files!

I suggest putting it to the warnings. E.g.: after WarningThermalRunaway.

[alextrical]

Yep, I noticed it was a smaller part of the solution, but is a great example of a functioning error message, that I can use to track down the relevant code to get it working correctly.

Than you for the heads up on the translations files, I will probably start by filling them all with dummy data. And then do a second pass with adding the translations for the error message

[alextrical]

Ive managed to get a warning to display, however it seems that the display still refreshes and removes the message from the display at maybe less than 1/10th of a second. I'm not sure how to trap the process in a For/While loop long enough to lock up the device at this stage.

  } else if (reading < 500) {
    // for (;;) /* Tip shorted, wait until reset */
    while (true)
    {
      OLED::clearScreen();
      warnUser(translatedString(Tr->WarningShortedTip), 3 * TICKS_SECOND);
      wait(10000);
      // OLED::refresh();
      __NOP();
    }

[Ralim]

The OLED should only be written to by the GUIThread, deliberately to avoid this issue.
Probably best action to do is to add to bsp.h some sort of function like isTipShorted() that returns a bool.

Then in the gui thread warnings area you can call it to check.

You will need to add a stub that returns false to all the other implementions (Pinecilv1,Miniware,MHP30,S60) for now.
(Technically TS101, TS80(P) can do this iirc but not fully implemented).

[Ralim]

I have updated this to have the translations; @alextrical could you give this a once over / test please 🙇🏼 ?

[ia]

Aaahh! I just was going to pick this up to help & to work on that too on this weekend, I swear. :D