suggestion : halInit returning status

[alex31]

Hello.

In the initialization of various modules, one can recognize a pattern :
° setting a bit in a register to start a peripheral
° loop forever, waiting for a bit in another register that tell us that peripheral has start

This is true for LSE, HSE, RTC, and probably more.

If for a reason, the peripheral don't start (crystal not fitted, capacitor badly soldered, peripheral not present on the current chip, etc), the program is just stuck in a forever loop,and one need to use a debugger to guess the problem.

Wouldn't be possible to set a reasonable timeout for all these operations, and return a bitmask of status operation in a msg_t ?

if return value is 0, all is fine, else, the bitmask list all the peripherals that have failed their init, and the program can find a way to indicate
a malfunction.

the change won't broke current application code, but can help new application code.

Alexandre

[Marco]

Hi Alexandre,

The initialization of these modules is very platform specific so i think it is not a good idea to let halinit return a bit mask of these failed peripherals.

Instead, I was having the following two ideas:

1. Adding a new failure state to the driver state machines, e.g. ADC_FAILURE.
   Once a driver is in the failure state all driver functions (except stop) return something like MSG_FAILURE to indicate something is wrong with the hardware. The driver can be stopped and started again to try to resolve the issue.
2. Adding a platform specific structure holding the status of all peripherals.
   The user can check the status if he wishes so, but can also just ignore it and try to continue using the peripheral.

Both options require a lot of changes so i'm not sure if this is feasible.

Giovanni, what do you think?

Marco

[steved]

I like the idea in principle - it could be very useful in production test of boards. 'Appears dead' is often the hardest condition to diagnose, since the production test mode generally uses limited test equipment and relatively unskilled people.

For best backward compatibility, maybe a global flag which selects between the current 'hang on problem' mode and a new 'return error on problem' mode. That way there's no risk of existing user code carrying on into a potentially critical area with known problems.

Ideally the returned error code would give an indication of the general area of the error(s) - a bitmask might work, with one bit assigned to each type of peripheral driver (rather than each individual peripheral); this would then be constant across Chibi. This could always be extended with peripheral-specific methods of getting a more detailed error where appropriate.

[Giovanni]

Hi,

Note that HW initialization does not happen in halInit() except for clocks, other drivers perform initialization in the start function.

I agree on the idea on principle, probably it would be better to define a failure state and a hook on the failure state enter, this because failure could also happen after initialization.

Anyway, I agree that HW failure != assertion.

Giovanni

[alex31]

Hello.

I trust the ChibiOS architect to find the best api that give the service :
° add a timeout at all the places where there is forever loop
° furnish a mean to retrieve failures

And enjoy your vacations Giovanni !

Alexandre