09-30-2019, 06:39 PM | #16 | |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Quote:
Code:
U-Boot 2009.08-dirty-svn ( 7月 16 2014 - 17:36:26) CPU: Freescale i.MX50 family 1.1V at 800 MHz mx50 pll1: 800MHz mx50 pll2: 400MHz mx50 pll3: 216MHz ipg clock : 66666666Hz ipg per clock : 66666666Hz uart clock : 24000000Hz ahb clock : 133333333Hz axi_a clock : 400000000Hz axi_b clock : 200000000Hz weim_clock : 100000000Hz ddr clock : 266666666Hz esdhc1 clock : 80000000Hz esdhc2 clock : 80000000Hz esdhc3 clock : 80000000Hz esdhc4 clock : 80000000Hz Board: MX50 RDP board Boot Reason: [POR] Boot Device: SD I2C: ready DRAM: 512 MB MMC: FSL_ESDHC: 0, FSL_ESDHC: 1, FSL_ESDHC: 2 In: serial Out: serial Err: serial [_get_sd_number] g_sd_number:2 MMC read: dev # 2, block # 1023, count 1 partition # 0 ... 1 blocks read: OK MMC read: dev # 2, block # 1024, count 1 partition # 0 ... 1 blocks read: OK PCB ID is 41 ESDin=0,UPGKey=-1,PWRKey=0 ram p=70000000,size=536870912 MMC read: dev # 2, block # 14335, count 1 partition # 0 ... 1 blocks read: OK MMC read: dev # 2, block # 14336, count 13205 partition # 0 ... 13205 blocks read: OK MMC read: dev # 2, block # 18431, count 1 partition # 0 ... 1 blocks read: OK no "logo" bin header MMC read: dev # 2, block # 45055, count 1 partition # 0 ... 1 blocks read: OK no "logo" bin header Kernel RAM visiable size=505M->505M init TPS65185 power ... Relock PLL1 to 1GHz ... mx50 pll1: 1000MHz mx50 pll2: 400MHz mx50 pll3: 216MHz ipg clock : 66666666Hz ipg per clock : 66666666Hz uart clock : 24000000Hz ahb clock : 133333333Hz axi_a clock : 400000000Hz axi_b clock : 200000000Hz weim_clock : 100000000Hz ddr clock : 250000000Hz esdhc1 clock : 80000000Hz esdhc2 clock : 80000000Hz esdhc3 clock : 80000000Hz esdhc4 clock : 80000000Hz Hit any key to stop autoboot: 0 MMC read: dev # 2, block # 2047, count 1 partition # 0 ... 1 blocks read: OK no kernel image signature ! MMC read: dev # 2, block # 2048, count 8192 partition # 0 ... 8192 blocks read: OK ## Booting kernel from Legacy Image at 70800000 ... Image Name: r7407_#3027 Aug 13 17:39:39 Created: 2014-08-13 9:39:41 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1953688 Bytes = 1.9 MB Load Address: 70008000 Entry Point: 70008000 Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. drivers/video/mxc/lk_tps65185.c(556):tps65185_int_func under-voltage on DCDC1 detected ! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=0! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=1! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=2! 1+0 records in 1+0 records out 512 bytes (512B) copied, 0.000220 seconds, 2.2MB/s cannot open /dev/null drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=3! dosfsck 3.0.6, 04 Oct 2009, FAT32, LFN There are differences between boot sector and its backup. Differences: (offset:original/backup) 489:8d/93, 490:ef/03, 491:02/81, 492:d2/03, 493:00/2a Not automatically fixing this. drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=4! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=5! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=6! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=7! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=8! /dev/mmcblk0p3: 207 files, 6669/3634233 clusters drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=9! (none) login: [PROGRESS_BAR-3009] No progess ... epdfbdc_set_width_height(1439): new DCSize(3342336)>original DCSize(3317760) ! sh: you need to specify whom to kill killall: fickel: no process killed killall: udhcpc: no process killed killall: wpa_supplicant: no process killed killall: ntpd: no process killed drivers/video/mxc/lk_tps65185.c(556):tps65185_int_func under-voltage on DCDC1 detected ! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=0! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=1! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=2! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=3! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=4! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=5! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=6! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=7! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=8! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=9! killall: fickel: no process killed killall: udhcpc: no process killed killall: wpa_supplicant: no process killed killall: ntpd: no process killed drivers/video/mxc/lk_tps65185.c(556):tps65185_int_func under-voltage on DCDC1 detected ! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=0! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=1! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=2! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=3! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=4! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=5! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=6! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=7! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=8! drivers/video/mxc/lk_tps65185.c(1352):wait power on timeout lpcnt=9! Power down. If this turns out to be true, disconnecting the screen might be a good diagnostic test. Time to try measuring some voltages on those tiny, tiny pins.... Stay tuned. Last edited by DomesticExtremis; 09-30-2019 at 06:41 PM. |
|
09-30-2019, 07:47 PM | #17 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Measuring voltages
Well, this is going to be tricky. The chip has four power modes correspnding to the Kobo modes as follows:
Code:
POWER DOWN Battery disconnected SLEEP Power down STANDBY Sleep ACTIVE Powered on |
Advert | |
|
09-30-2019, 07:52 PM | #18 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Moreover, there are power rail dependencies, meaning that not everything comes on at once:
Code:
8.3.2 Dependencies Between Rails Charge pumps, LDOs, and VCOM driver are dependent on the positive and inverting buck-boost converters and several dependencies exist that affect the power-up sequencing. These dependencies are listed below. • Inverting buck-boost (DCDC2) must be in regulation before positive boost (DCDC1) can be enabled. Internally, DCDC1 enable is gated by DCDC2 power good. • Positive boost (DCDC1) must be in regulation before LDO2 (VNEG) can be enabled. Internally LDO2 enable is gated DCDC1 power-good. • Positive boost (DCDC1) must be in regulation before VCOM can be enabled. Internally VCOM enable is gated by DCDC1 power good. • Positive boost (DCDC1) must be in regulation before negative charge pump (CP2) can be enabled. Internally CP2 enable is gated by DCDC1 power good. • Positive boost (DCDC1) must be in regulation before positive charge pump (CP1) can be enabled. Internally CP1 enable is gated by DCDC1 power good. • LDO2 must be in regulation before LDO1 can be enabled. Internally LDO1 enable is gated by LDO2 power good. The top half of the typical application gives a hint as to some useful measuring points and pins of interest. |
09-30-2019, 08:07 PM | #19 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Finally the pinout for the chip (attached), and a list of things to measure:
1. battery voltage 3.3 - 4.2V 2. Pins of interest: Name Pin Description Voltage(min/typ/max) --------- ----- ---------------- -------------------------------- VIN 10 Input power supply to general circuitry. 3.0/3.7/6.0 VIN_P 24 Input power supply to inverting buck-boost converter (DCDC2). 3/3.7/6 VN_SW 25 Inverting buck-boost converter switch out (DCDC2). -16V VN 26 Feedback pin for inverting buck-boost converter (DCDC2) and supply for VNEG LDO and VEE charge pump. 16v(?) VB_SW 40 Boost converter switch out (DCDC1). 16V PGND1 41 Power ground for DCDC1. 0V VB 42 Feedback pin for boost converter (DCDC1) and supply for VPOS LDO and VDDH charge pump. 16V(?) Simples... Last edited by DomesticExtremis; 09-30-2019 at 08:13 PM. |
10-01-2019, 08:05 PM | #20 | |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Well, I said it was going to be fiddly, and it is.
Not only do I have a very short time window to work with before the chip shuts itself down, but the pins are so tiny that my multimeter probes look like giant's fingers by comparison. So far I have measured the battery at 4.12V and VIN (pin 10, power to the whole chip) at 4.11V. Which is good as it tells me we definitely are getting the right amount of voltage through the system and that there is no UVLO in play. Actualy, a ;ittle more can be gleaned from this - from the datasheet: Quote:
Last edited by DomesticExtremis; 10-01-2019 at 09:07 PM. |
|
Advert | |
|
10-02-2019, 12:51 PM | #21 |
cosiñeiro
Posts: 1,271
Karma: 2200049
Join Date: Apr 2014
Device: BQ Cervantes 4
|
Wow, @DomesticExtremis, You did your own research.
Probably you're right on the various low level bits. I hadn't time to check. My suggestion about UVLO was just after a quick read of the datasheet, but given there's an specific error for that on kernel sources I would came to the same conclusion as you: not our problem. Please keep in mind that the PMIC you're exploring is just for driving power to the screen and shouldn't have the capacity of powering the whole system down. There is another PMIC based on MSP430 that's driven via i2c and that handles the various bits exposed to linux (battery, frontlight, GPIO...) and it is the one that could reset the SoC on demand. https://github.com/pazos/linux-2.6.3.../mxc/pmic/core On my Kobo Aura HD it has its own serial header (labeled J2) but it just produces gliberish data connected at standard baud rates from 9600 to 115200. |
10-02-2019, 12:55 PM | #22 | |
cosiñeiro
Posts: 1,271
Karma: 2200049
Join Date: Apr 2014
Device: BQ Cervantes 4
|
Quote:
I'm sorry but my english is not good and this is a bidirectional problem, both Input and Output |
|
10-02-2019, 03:13 PM | #23 | |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Quote:
If disconnecting the screen has made a difference to the errors seen, we might conclude that the screen is the problem. It did not change any errors, so I inferred that the problem was with the chip, not the screen. Really, we need one with a known broken screen to repeat the test and see for sure what happens. (i'm not planning to break my screen just for that though ). |
|
10-02-2019, 03:23 PM | #24 | |||
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Quote:
Quote:
ETA: actually the eReader is not in sleep mode because the front light stays on. It just fails to boot fully according to the console messages. However the chip goes into standby, as it would if the eReader were sleeping. Quote:
Last edited by DomesticExtremis; 10-02-2019 at 03:42 PM. |
|||
10-02-2019, 07:01 PM | #25 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Volts!
Phew!
After much fiddling and faffing and going bozzeyed, we have some voltage measurements (see attached table). Pin (number) and (pin) name should be self explanatory. The TP after the pin name indicates a point on the circuit where is is slightly easier to measure with elephantine multimeter probes. I found these by inspecting the traces, checking continuity to the appropriate pin and checking measurements at both pints. A and K are anode and cathode respectively for a diode. For the capacitors, us the end connected to the pin by inspecting the traces. Note also I used a digital multimeter which is sluggish in response, so some of the voltages could not be accurately measured before the chip went from active to standby mode. Just to recap: Sleep corresponds to eReader powered down Standby corresponds to eReader in sleep, or after failing to boot (in this case) Active corresponds to the eReader at power-up and before the chip reverts to standby (after two or three seconds). Also attached is the application example circuit from the datasheet which, unsurprisingly, is almost identical to that on the board. The test points have been added in for reference. Last edited by DomesticExtremis; 10-02-2019 at 08:21 PM. |
10-02-2019, 07:19 PM | #26 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Battery voltage was 4.15 to 4.1 volts after many power cycles to do the measuring.
Other than the stray voltage on VIN, I think we can see that the input power to the chip is fine and as expected, as is the regulated 3.3V to pin 45. Pins 24,25 and 26 are for the DCDC2 negative voltage boost converter. Here too, the input voltage VIN_P (pin 24) looks fine at near battery voltage and within spec. Pin 25 is VN_SW, the inverter output and stays resolutely at zero, after several attempts to measure it. However pin 26 does shoot up (perhaps down) to a value near the required -16V. I found it difficult to measure exactly because my meter is sluggish and the window for measuring this value is very brief. I am prepared to accept that it does attain its correct value, just that I am not able to measure before the chip reverts to standby mode. Quite why VN_SW stays at zero I don't understand, particularly since it feed the other end of the diode to VN, so there should only be a diode drop (min 0.3V) of difference in the voltages of pins 25 and 26 (unless I misunderstand the circuit, which is eminently possible). It may be that the diode has failed open circuit but that no error is reported because the chip measures VN and not VN_SW. Anyhoo, moving on to pins 40,41, and 42 for the DCDC1 boost converter which should be supplying the +16V rail, there is something really weird going on. In standby mode there is a small voltage on both VB nd VB_SW. In active mode these values are slightly lower, but nowhere near in spec. Again the two pins are joined by a diode, so their voltages should not be equal. It is possible that the diode is shorted and causing the failure of the boost circuit, However two failed diodes around the same chip at the same time seems unlikely, more likely is an internal failure in the chip. Last edited by DomesticExtremis; 10-02-2019 at 08:22 PM. |
10-02-2019, 07:21 PM | #27 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
As Columbo used to say, just one more thing...
I need to test the support components around DCDC2 and DCDC1 to check for failed diodes and/or shorted capacitors. If there are none, we can conclude that the chip is funculated and needs to be changed. I will need to disconnect the battery and remove the board to do that, so not tonight. Stay tuned... Last edited by DomesticExtremis; 10-02-2019 at 08:23 PM. |
10-05-2019, 03:32 PM | #28 | |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Quote:
|
|
10-13-2019, 08:21 PM | #29 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
Right, so , after a brief hiatus where life got in the way of doing something of interest, I'm back.
At this point I'm 90% certain that my screen is not broken and 80% certain that the TPS65285 PMIC chip is faulty based on the boot error messages and the voltage measurements. However, the chip has a substantial number of external support components - diodes, resistors, capacitors and inductor coils any one or more of which might have failed and be responsible for the chip failing to fully power up. I can limit myself to just investigating the external components attached to the DCDC2 and DCDC1 subsystems: the former needs to be working prior to powering up the latter. Together these two provide the power rails for the EPD function of the screen. This exercise is based on the assumption that the typical application circuit in the TPS65185 datasheet is what is implemented on the Kobo motherboard. As it turned out this is almost true, the Kobo also has some extra filter capacitors beyond those indicated on the diagram. |
10-13-2019, 08:37 PM | #30 |
Addict
Posts: 243
Karma: 359054
Join Date: Nov 2012
Device: default
|
The next problem is to find the physical location of the components on the board. Lickily all of the support components ahve only two pins, so the circuit was traced out using the following steps:
After inspecting the relevant parts of the diagram we are only interested in a couple of diodes, a few capacitors and some inductors. Inductors can burn out, so would fail open circuit. Capacitors usually fail short circuit. Diodes can fail short circuit or open circuit (aiui). Measuring the component values in-circuit can give misleading results, so I just tested for open/short circuit. I mention the above for the benefit of those who might think I know what I am doing. I don't |
Tags |
bricked |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Aura H2O Vcom voltage changing | m4103 | Kobo Developer's Corner | 0 | 09-29-2018 07:51 AM |
K3 battery voltage? (I²C details) | Popup | Kindle Developer's Corner | 42 | 10-12-2012 05:05 PM |
battery voltage | p3aul | Sony Reader | 10 | 05-01-2010 02:40 AM |
PRS-300 Voltage on AC Chargers | Shopaholic | Sony Reader | 5 | 02-04-2010 05:26 PM |
Is the PRS Auto-voltage? | orien | Sony Reader | 2 | 05-15-2008 02:48 AM |