zadammac / peti Goto Github PK

Some of the installer instructions are wrong too. Maybe walk through the process on a VM just for giggles to make sure we get it right.

The RNG appears to have a period on the order of 8-15 draws.

This could be improved by focusing on the least significant bits of the RNG result before converting to a float and handing it out. I'd hope it to be an easy fix.

The position of Resistor R3 is wrong, and worse, the resistor itself is superfluous.

Because it stands between the Low Battery (LBO) pin on the TPS module and the matched GPIO pin on the microcontroller, the line is constantly pulled high to the level of the main 3.3v rail; that is, the low battery signal is never sent.

By removing this resistor the issue is resolved in f/power-management-enhance's recent commits; using the internal pullup resistor on the MSP430 more than suffices.

Users of revision C development kits should cut resistor R3 off the board or otherwise remove it. TODO: remove from revision D before committing the schematics.

Describe the bug
At first boot, the pet will not be animated regardless of player actions until the first time an Alert is raised, which seems to fix the issue for an unknown reason. This issue seems to only occur in debug, when sending the pet directly to Stage 1 and skipping the egg stage. It does not necessarily occur on every boot.

To Reproduce
Steps to reproduce the behavior:

1. Install 0.3.0.
2. Put the device in debug mode.
3. Clear save data (if needed)
4. Set the RTC (if desired)
5. Pet will be observed not to move for an extended period of time.

Expected behavior
The pet should proceed with his usual metanimation and animation cycle rather than sitting still.

Desktop (please complete the following information):

• Version: 0.3.0
• Hardware Revisions: CDB B/REB D

Additional context
Add any other context about the problem here.

From main.c, we have the main program loop which triggers roughly 2 Hz:

    while (1){
        PMM_unlockLPM5();
        GAME_evaluateTimedEvents(); // < - this is relevant
        Update_Button_States();
        SCENE_updateDisplay();
        ToggleVCOM();
        __bis_SR_register(LPM0_bits | GIE);
    }

Then from the game_manager.c source code:

    if (current_seconds == 0){ // At the round minute, we need to check for these several functions, none of which actually exist yet.
        GAME_NEEDS_evaluateHungerFun(current_minutes);

So, every minute, if the RTC says we're at zero seconds past the minute (the first second of the minute), we call the hunger-fun func.

That func is a funky func which takes the "rateHF" property, figures out the hunger and fun degredation rates as values from 0 to 15, and does whacky math to work that out into a rate of "number of points by which to degrade hunger or fun in a 15 minute period"

TECHNICALLY, therefore, there is no bug. In a 15 minute period, with a hunger-decay rate of 15, you'll lose 15 points of hunger in any situation. Like god intended.

BUT, there is a very narrow condition where the per-minute decay rate doubles, because the main program loop is being triggered by a register of Timer A0 and the check to run the evaluator is being governed by the RTC's seconds register. Technically both are being fed by the system clock, but since one can interrupt and the other can't, they drift into and out of alignment.

If they're fully aligned and the heartbeat rate in A0 is actually 2hz (it's only ROUGHLY) 2hz for reasons, you could briefly experience per-minute hunger rates of 2 points per minute in the above scenario. If you somehow maintained that state for a full 15 minutes you could even double the rate-that-matters, but that should be VIRTUALLY IMPOSSIBLE given the state of the clock.

y tho?

We can see from the behaviour of the display capture utility that the screen is being fully rewritten on every frame. This is going to be a fairly small logic bug.

Is FORCE_REFRESH being used correctly in all the places it's called?

Behavior: The LED_ALERT LED remains lit after initially lighting, even once a human has interacted with the pet (e.g. by having touched an input button)

Expected behaviour: Pressing any of the input buttons should clear the LED alert light (by turning it off) until the next alert is triggered.

Likely this was caused when the human input stuff was changed in the previous megamerge.

Specifies TPS60205, should be TPS60204.

Difference: The ~5 has a "battery good indication" circuit rather than low battery detection. Fundamentally changes the behaviour of the overall circuit to use that component.

The correct component is listed in the Service Manual's BOM.

The printTextLarge function call makes a strange assumption regarding bitmap_right and bitmap_left, namely that the right half of the character is stored at a lower index than the left half of a character. This does not make sense when considering the normal design and storage of font files.

Correcting this issue will be included in the 0.4.0 update to better improve support for the overall transition to fontx2 source files.

When entering the "stage select" mode via the debug menu, the screen will go blank. Subsequent BOR does nothing to relieve the condition.

Inspection via Debugger reveals the following behaviour:

• The button press to select the stage select option is registered
• The function in the debug menu which corresponds to this triggers, and sets SCENE_ACT correctly to 0xF3, the registered address for that scene.
• The menu generator correctly generates the subsequent frame of information (Note: This is disputed, reconfirm)
• The screen refresh happens correctly.
• The menu generator exit condition is met and we leave the scene.
• The VCOM transition happens as intended.
• The instruction to enter LPM is reached.

Thereafter the execution pointer appears to leap into the bootloader in perpetuity.

Presumably this happens because we do not actually initialize or start the RTC without saving the output of the menu. Needs investigation.

There are two issues with the gerber files for the button inputs board:

• The dimensions of the header footprints are wholly wrong and incompatible with the parent board without significant jerry-rigging or specialty headers, and;
• The "cross members" that make up the top and bottom edges of the window for the display are a little thin, leading to some flexibility where it is not desired.

This is only a problem if you do not intend to use perfboard, but should be corrected as part of the architecture rewrite project.

During a livestream on patcharcana on April 5, 2023 it was noticed that the menu bars top and bottom of the screen are being redrawn on every frame.

This is considerably overtaxing the system; while the rendering is probably minor it means SPI traffic is being sent that doesn't need to be sent. Furthermore this was thought to be corrected several versions of the firmware ago.

There is a design flaw in the Revision B Rear Expansion Board (REB); alternatively in the dev kit overall, depending on the desired resolution.

The REB presupposes that it will always receive "sufficient" power from the two AA batteries held in series. This is nominally true for the purposes of running the MSP430fr5994 and most of the accessory components. However, the SHARP LCD requires a minimum input voltage of 3V.

This power input voltage is driven from the GPIO pins on the MSP430. The 430 has power management, but no voltage regulation, and digital out is always limited to Vcc, which is the voltage recieved from the input pin, ie the voltage of the battery pack.

When driving this with alkaline or carbon batteries, with a nominal voltage of 1.5V per cell, this is fine and we get enough voltage to drive the display. This was how the power circuit was validated before the boards were milled.

However, when driving with NiMH rechargeable batteries, each cell has a nominal voltage of 1.2 V and even in series we fall ~0.5V below the threshold to drive the display.

For the purposes of the Dev Kit this is not necessarily an issue; in fact, the flatened curve makes it faster to test things like battery degredation and handling low battery conditions. However, for the final toy design and maybe even as an experiment with the dev kit, it would be nice to fix this problem, by either:

• Implementing some kind of power management between the battery package and VCC which would hold the 3V3 rail up around 3 V, potentially requiring a re-imagineing of the low-voltage detection circuit (And likely a rev C of the Rear Expansion Board), and;
• Implementing similar voltage conversion for at least the LCD-Power (and possibly other LCD driver pins) as a shim module between the controller and the display, which has its own limitations.

A decision on how to fix this problem is due by February 28, 2022

The designs for the Rear Expansion board are missing from the repo, so there's your first problem.

They are also flawed in the following ways:

• The footprint for a resistor to the buzzer is missing. I believe this is actually by design but we need to revalidate.
• the expansion SPI header is at the wrong pitch. It's on the board as 1.1mm but should be 1.5 mm. Yes. That matters.
• the expansion headers at J1 and J2 are also wrong and need to match the ones used on the buttons daughterboard, which I believe is also 1.5mm. Without this the board cannot be connected to the main dev board, which defeats the point.
• The corner through-holes are SLIGHTLY misaligned. This may not cause issues with the standoffs but it would be nice to adjust them slightly to be absolutely sure.

The version of main.c at master is broken. Use b903c97 instead.

This issue was caused by me being an idiot and not testing an MR; won't happen again.

I've solved this issue at least once before and should be able to correct the codebase with some minor changes (that will also improve readibility IIRC) but don't have the clean file and will need to take care of that later.