Yeah, but that is not done because this is acceptable style, but because SDCC is not able to remove unused functions from the binary... I know I am also guilty of this, but generally no code should be in the include files.
I haved documented the code options and how to use them here: https://free-pdk.github.io/tutorial#code-options
Yup. Tried every boolean combination of Button First | Plugging In | Button While Doing lsusb. No change in the output.
Does your device enumerate when you plug it in while the button is pressed? It should show up as "STM32 BOOTLOADER". If it does not, then there is certainly a hardware issue, like a solder bridge or incomplete connection. Trying to program the device with SWD will not make that issue go away. Choose wisely where you spend your effort
Did you check the 3.3V supply? Did you check the USB connection on the PCB?
I feel like quite the fool now. It turns out that tacky flux like you'd use in a reflow oven is quite the insidious chemical.
All I had to do was replace the button, flux seems to have wormed its way inside and disabled it. A fresh button from the batch passed continuity, the original didn't.
One sudo whack at it later and it's flashed. Next will be getting it to talk to a real chip, it complains there's "nothing found" with more verbosity saying "command ack failed / wrong icid".
I guess it's round two with the multimeter
I wonder if a dunk in isopropyl would clear the button out. Not like I don't have a dozen more on hand, but I might still try it as an investigation of the flux.
I certainly won't be doing the next board the same way!
I feel like quite the fool now. It turns out that tacky flux like you'd use in a reflow oven is quite the insidious chemical.
All I had to do was replace the button, flux seems to have wormed its way inside and disabled it. A fresh button from the batch passed continuity, the original didn't.
One sudo whack at it later and it's flashed. Next will be getting it to talk to a real chip, it complains there's "nothing found" with more verbosity saying "command ack failed / wrong icid".
I guess it's round two with the multimeter
I wonder if a dunk in isopropyl would clear the button out. Not like I don't have a dozen more on hand, but I might still try it as an investigation of the flux.
I certainly won't be doing the next board the same way!
Yeah, after a couple iterations, the typical points of failure become obvious
You should compile "easypdkprogtest" and check for the voltages to verify that the programming voltage control works properly.
Hmm... what are the voltages supposed to be? I got 19.83, 5.01, and vref=3.31.
Based on the source for the test, pressing the button should light an LED, but it didn't.
Also, there's a keypress time-out function, but it didn't respond to that either. I had to kill the program with ^C.
Gave it about four runs, same results each time... but now the programmer's just vanished from USB. I guess something failed on the board and took the STM offline.
Uhm, the voltages should be 5.0 V, 5.0V and 3.3 V. 19.85 certainly is too high, this is even above the nominal boost converter output. Did you miss any resistors anywhere, or are some values are mixed up?
I have been working with the PFS173 again, only to bump into some additional oddities. Not sure where else to document this:
Power on reset
It seems that the PFS173 power on reset does not work if the slew rate is too low. My power supply takes around 50 ms to ramp to final voltage. This will lead to the PFS173 not starting at all. See waveform here:
When I detach and attach the connection manually, everything is fine:
11 Bit PWM
It took me quite a while to figure out why the PWM frequency was never the one I tried to set: The 11 Bit PWM is actually a 10 bit counter. The eleventh bit is generated by a ANDing the LSB with the clock. Therefore only 1024 maximum counts should be assumed when calculating the PWM frequency.
It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.
It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.
The latter is true, see also https://free-pdk.github.io/tutorial#registers
It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.
The latter is true, see also https://free-pdk.github.io/tutorial#registers
Hm... I cannot imagine that all registers contain random values at reset, because there certainly are some combinations that would cause undesireable behavior.
Maybe only a few registers are off. But that's something that can be easily checked.
Hm... I cannot imagine that all registers contain random values at reset, because there certainly are some combinations that would cause undesireable behavior.
Maybe only a few registers are off. But that's something that can be easily checked.
True - the wording can certainly be improved. When I wrote "undefined", I meant "is initialized to a fixed value that may differ from the datasheet, therefore its better to always set all registers explicitly". Of course, it would be even better to have a definitve list of all µCs and their respective true initial register values.
Dumping initial state of I/O area
00: F0 F0 A6 9E 00 08 00 00
08: 00 00 00 00 00 00 00 00
10: 20 00 00 00 00 00 00 00
18: 00 00 00 00 00 00 00 00
20: 40 00 FF E0 E0 E0 E0 E0
28: E0 E0 E0 00 00 E0 60 61
30: 00 00 00 00 00 00 00 00
38: 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00
48: 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00
58: 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00
68: 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00
78: 00 00 00 00 00 00 00 00
Dumping initial state of I/O area
00: F0 55 A6 9E 00 08 00 55
08: 55 55 55 55 55 55 55 55
10: 20 00 00 00 00 00 00 55
18: 00 00 00 55 55 55 55 55
20: 40 00 FF E0 55 55 55 55
28: 55 55 55 00 55 E0 60 21
30: 00 00 55 55 00 00 55 55
38: 55 55 55 55 55 55 55 55
40: 00 55 55 55 55 55 00 55
48: 55 55 55 55 00 55 55 55
50: 55 55 55 55 55 55 55 55
58: 55 55 55 55 55 55 55 55
60: 55 55 55 54 55 55 55 55
68: 55 55 55 55 55 55 55 55
70: 55 55 55 55 55 55 55 55
78: 55 55 55 55 55 55 55 55
Hm... there seems to be something undocumented at the adresses 0x2d, 0x2e, 0x2f
Hmmm.... 0x2d is cleary a control register. Reset state is 0xE0. Bits 7-5,3,1,2 are R/W, Bits 4 and 2 RO. 0x2e and 0x2f appear to be read only.
Any ideas what could this be? It's also not mentioned in the official includes. These could possibly be test registers.
Hm... there seems to be something undocumented at the adresses 0x2d, 0x2e, 0x2f
Hmmm.... 0x2d is cleary a control register. Reset state is 0xE0. Bits 7-5,3,1,2 are R/W, Bits 4 and 2 RO. 0x2e and 0x2f appear to be read only.
Any ideas what could this be? It's also not mentioned in the official includes. These could possibly be test registers.
I think I have an idea what it could be...
Some time ago when I was deep into research I found out about the really undocumented RFC (Resistance to Frequency Converter). This might be used as a poor men's touch interface or ADC?
You can still find some comments only in some of the PDK .INC files.
After digging a bit deeper I found some info in an old Puolop datasheet for PTBO165C : http://www.htsemi.com/xiazai.aspx?aa=/include/upload/download/_20180709113738742.pdf&bb=PTBO165CXXS
Sections 3 and 4:
3. RF Inverters Functions Description
4. RFC (Resistance to Frequency Converter) Functional Description
This small data sheet explains register settings and how to use them. From the PDK .INC files it is also obvious that this feature is present in some more IC (not only in 165C). Maybe it is just not working and that's why missing from data sheet or it is sold as extra feature in different IC marketing derivates.
RFCC IO_RW 0x36 (0x2D, -)
$ 7 ~ 5, 0 : PA4, PB4, PA0, PB3, X, PB2, X, PB1,
PA3, PB0, PB7, X, PB6, X, DISABLE : 0xE
$ 4 : X, START : WR_BIT
$ 3 : R_TYPE, C_TYPE // PA4 only for C_TYPE
// ICE Only support R_TYPE
$ 2 : X, Overflow
$ 1 : X, Output // PB5
RFCCRH IO_RO 0x37 (0x2E, -)
RFCCRL IO_RO 0x38 (0x2F, -)
interrupt latency
I measured interrupt latency to be 6 cycles till the first instruction of the interrupt handler. Can anyone confirm this? Jitter is 2 cycles, assuming an infinite rjmp loop in the main program.
It seems that the PFS173 spends two more cycle on something else...
Dumping initial state of I/O area
00: F0 55 66 9E 00 87 00 55
08: 55 55 55 55 55 55 55 55
10: 01 00 00 55 00 00 00 55
18: 00 55 54 55 00 00 55 55
20: 00 55 55 55 55 55 00 55
28: 55 55 55 55 00 55 55 55
30: 55 55 00 00 55 55 F4 00
38: 00 55 55 55 55 55 55 55
JS, would you please add the STM32 Bin file along the DFU one too,
In a new design I have connected bootpin to ground, I can only program the STM32 with j-link and it would accept bin file or hex file.
Thanks
Thanks JS,
How we can set LVR for PFS173,
Is there any example code?
I want to set it to 4.0V