FreeCalypso > hg > freecalypso-tools
comparison target-utils/libbase/abbdrv.c @ 497:74610c4f10f7
target-utils: added 10 ms delay at the end of abb_power_off()
The deosmification of the ABB access code (replacement of osmo_delay_ms()
bogus delays with correctly-timed ones, which are significantly shorter)
had one annoying side effect: when executing the poweroff command from
any of the programs, one last '=' prompt character was being sent (and
received by the x86 host) as the Calypso board powers off. With delays
being shorter now, the abb_power_off() function was returning and the
standalone program's main loop was printing its prompt before the Iota chip
fully executed the switch-off sequence!
I thought about inserting an endless tight loop at the end of the
abb_power_off() function, but the implemented solution of a 10 ms delay
is a little nicer IMO because if the DEVOFF operation doesn't happen for
some reason in a manual hacking scenario, there won't be an artificial
blocker in the form of a tight loop keeping us from further poking around.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Sat, 25 May 2019 20:44:05 +0000 |
| parents | 3d73d4d3527f |
| children | 44a1de4264d8 |
comparison
equal
deleted
inserted
replaced
| 496:3d73d4d3527f | 497:74610c4f10f7 |
|---|---|
| 100 abb_power_off() | 100 abb_power_off() |
| 101 { | 101 { |
| 102 abb_init(); | 102 abb_init(); |
| 103 serial_flush(); | 103 serial_flush(); |
| 104 abb_reg_write(VRPCDEV, 0x01); | 104 abb_reg_write(VRPCDEV, 0x01); |
| 105 /* | |
| 106 * TWL3025 datasheet seems to indicate that the time for the DEVOFF | |
| 107 * command to take effect is 5 cycles of the 32.768 kHz clock. | |
| 108 * We'll do an ARM-timed delay of 10 ms before returning from | |
| 109 * this function. | |
| 110 */ | |
| 111 wait_ARM_cycles(13000 * 10); | |
| 105 } | 112 } |
