Just use 0x0 and 0xFFFFFFFF

NUM_OF_BATTERY_REGISTERS - 1

Put 2 items at end of the list here:
BATTERY_END_OF_LIST_TIME_TO_PUBLISH
NUM_OF_BATTERY_REGISTERS

Put this one back to NUM_OF_BATTERY_DEVICES.

Don't need min/max for this. Just use 0x0 and 0xFFFFFFFF where needed.

I don't think we need these min/max #defines. Just use 0x0 for minimums and 0xFFFFFFFF for maximums.

· /firmware/App/Controllers/BloodFlow.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/ModePreTreat.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/ModeTreatment.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/ModeTreatment.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxBloodPrime.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxBloodPrime.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxDialysis.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxDialysis.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxPaused.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxPaused.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Monitors/Pressures.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtSWFaults.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtTD.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/DDInterface.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/DDInterface.h	(-2, +2)	| History	| Source	| Diff
… 7 more files in changeset.

]]> Fri, 05 Jun 2026 10:08:02 -0700 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1 Sean Nash finished reviewing LEAHI-TD-FIRMWARE-LDT-4013-1 LEAHI-TD-FIRMWARE-LDT-4013_Fluid Bolus - FW Implementation - 2/4: ]]> Thu, 04 Jun 2026 09:52:42 -0700 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1 Vendor - TEL - Jashwant Gantyada finished reviewing LEAHI-TD-FIRMWARE-LDT-4013-1 LEAHI-TD-FIRMWARE-LDT-4013_Fluid Bolus - FW Implementation - 2/4: ]]> Thu, 04 Jun 2026 09:35:19 -0700 Vendor - TEL - Praneeth Bunne https://devapps.diality.us/changelog/td-firmware?cs=58d4338b0c453ac49d3fdc4ba391b47949406b98 https://devapps.diality.us/changelog/td-firmware?cs=58d4338b0c453ac49d3fdc4ba391b47949406b98 Vendor - TEL - Praneeth Bunne committed 58d4338 on branch LDT-4013-fluid-bolus, LDT-4329-edit-treatment-parameters-during-treatment and 2 more in td-firmware LDT-4013: Merge latest staging into LDT-4013, resolved merge conflicts and addressed CR comments

· /firmware/App/Modes/ModePreTreat.c	(-18, +203)	| History	| Source	| Diff
· /firmware/App/Modes/ModeTreatment.c	(-12, +23)	| History	| Source	| Diff
· /firmware/App/Modes/ModeTreatment.h	(-18, +19)	| History	| Source	| Diff
· /firmware/App/Monitors/Pressures.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtSWFaults.h	(-5, +12)	| History	| Source	| Diff
· /firmware/App/Services/Messaging.c	(-3, +71)	| History	| Source	| Diff
· /firmware/App/Services/Messaging.h	(-61, +23)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/FluidBolus.c	(-0, +635)	| History	| Source
· /firmware/App/Services/StateServices/FluidBolus.h	(-0, +75)	| History	| Source
· /firmware/App/Services/StateServices/TubeSetAutoEject.c	(-0, +437)	| History	| Source
· /firmware/App/Services/StateServices/TubeSetInstall.c	(-0, +335)	| History	| Source
· /firmware/App/Services/FluidBolus.c	(-628, +0)	| History	| Source	| Diff
· /firmware/App/Services/FluidBolus.h	(-75, +0)	| History	| Source	| Diff

]]> Thu, 04 Jun 2026 09:00:19 -0700 Sean Nash https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1/#c29616 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-1/#c29616 Sean Nash commented on LEAHI-TD-FIRMWARE-LDT-4013-1

Should this check be moved to the fluid bolus exec function?

It looks like you have this as a T/F response from UI. UI should not be determining whether the modality matches - that's our job. UI should be telling us which type of tubing set was installed (HD or HDF type). Then when we get this response msg from UI, we will compare the type to the user selected modality (from TxParams) to see if it matches.

Add doxygen comments to the right of each structure field.

Why is this commented out? We will get stuck in this state if we don't move on to the pressure leak test states.

For now, we need to set authResponseReceived and authResponseValidTubingSet and authResponseModalityAccepted to TRUE until UI is properly responding to authentication request (TODO).

For now, we need to set barcodeScanResponseReceived to TRUE here until barcode scan command is implemented.

Add blank line before return statement.

Keep this blank line above group header.

Something is wrong here. We already had reg 33 at line 192 above. Reconcile with HDD.

Make sure UI s/w is looking for this message on the broadcast channel or change this channel to the TD=>UI channel if UI is looking for this message on that channel.

Maintain alphabetical order.

Eliza says we do allow multiple iso UF sessions in a treatment. So do we still need this else if, but looking at <= iso UF elapsed session time?

What about HDF?

Once UI software sends the volume and/or duration change request and once we change them, the UI software will send another request to confirm the displayed settings to the user and that is what is being handled in this function.

return result;

Keep local result and set to TRUE or FALSE with a ternary.

Which setting does this message confirm (duration or volume)?

Align comment.

where are we calling an alarm?
i think we are only sending event change data in completeBolusToCumulative() right?