LeafLabs Garden » Topic: PMBus on STM32F103CBT6... ???

LeafLabs Garden » Topic: PMBus on STM32F103CBT6... ??? http://forums.leaflabs.com/topic.php?id=74270 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:05:17 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105297 Wed, 19 Mar 2014 04:32:34 +0000 rp 105297@http://forums.leaflabs.com/ I'm thinking of doing something like what's in ring_buffer for type i2c_msg for queing I2C transactions. Should work fine. Then, transactions can be picked off the end when processed by the main code, new ones can be added as long as the buffer isn't full (of pending, in-process, or completed transactions not yet processed by main()). In considering how to save space, I'm wondering how much I can simplify transaction halding in the ISR - I don't want to overdo it. What I have right now is very flexible, but somewhat tedious to set up - and depending on how many different forms of I2C communication are required, could take a fair bit of RAM. Hmmm... Already thinking ahead regarding USART message handling - I should be able to use the CRC calculation function with USART, that's the only place I think I'll need it. The PC host interface protocol I've been working on is one-by-one, each requiring a response to ensure successful tx / rx, no response if tx fail (timeout on both sides, re-send). Still, I wonder about something like porting ZModem to the STM32 instead. Probably too big, though. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105287 Sun, 16 Mar 2014 02:47:47 +0000 rp 105287@http://forums.leaflabs.com/ More info... So far (running about 20 mins straight), the ISR works with a PCA9685 PWM controller. I have a servo driven by the PCA9685 moving from end to end and back over time, then read voltage / margin voltage / read voltage from the DC to DC converter and repeat. In actuality, I won't have the PCA9685 on the same bus as the DC to DC converters, the 2 PCA9685's will get their own bus. The DC to DC converters will be on the same bus as the MPU-9150, though. No breakout board for the MPU-9150, so next round of testing (perhaps later today) will be on my custom board. I'll also be able to work on simultaneous I2C transactions (ex, read / write to the converters and the MPU-9150 on I2C1, while streaming positions out to the PCA9685's over I2C2). I'll also be able see how much CPU time I have when the ISR isn't firing while I2C communication is ongoing. So, I have PMBus / SMBus devices working with a regular I2C device at 400khz on the same I2C bus with no issues. This exactly what I was hoping for - so far, so good. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105273 Mon, 10 Mar 2014 16:59:52 +0000 rp 105273@http://forums.leaflabs.com/ After cleaning things up, I have some numbers: * For 6 bytes (Rx, repeat start), including PEC, 174 uS at 400 khz (micros()). * For 4 bytes (Tx, no repeat start), including PEC, 100 uS at 400 khz (micros()). All works, nothing broken on refactoring / cleanup. I was able to load up the Rx sketch, read 6.05v repeatedly, reset the board, loaded up the Tx sketch, issued the margin down repeatedly, reset the board, loaded the Rx sketch again, read 5.45v repeatedly. Actually, I can see some jitter in the voltage readings, but that's expected. No PEC errors, and I've seen them in testing (ex, stop in the wrong place). I'm fairly certain I'm setting stop (the ISR quits firing), so I doubt I'll test it with a DSO / logic analyzer / etc. Next step is to do both Tx and Rx back to back without going through reset / re-enable. Being that the state of the ISR / peripheral is stable, I don't expect any problems. One thing I want to do is queue up transactions so there's always data ready to go out over the I2C bus (this is needed for PWM, I'll be doing a lot of position updates over I2C). I might need to add a check for the MSL bit following stop, otherwise, I'll have a queue where I can check the status of the transaction from the main code and remove the msg before queuing next. And WOW, is USBSerial SLOW!! :) I know why, and that's why I have a CP2103 USB to UART chip on my custom board. *** Just tested, and yes, it works with back-to-back rx / tx / rx (repeated). Woohoo!! rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105272 Mon, 10 Mar 2014 02:22:13 +0000 rp 105272@http://forums.leaflabs.com/ More success... Just found two "oops" code mistakes in the last few hours, and sure enough, once those were resolved, I was able to remove the BTF / TXE / RXnE shortcut I had in there. Also fixed a problem I had on 2nd attempt at tx or rx. And, there is no need to disable the IRQ flags (something I was trying to avoid), they can stay active the whole time, and it doesn't misbehave. All I have to do is set a transaction (send or receive) and set SB (start), and the ISR does the rest. Operation is very clean at this point (but the code isn't, lots of testing garbage to take out), it's doing what I had intended. I fought this thing all day long and into the wee hours, thinking I was overlooking something - finally found it. So, SMBus / PMBus Rx and Tx are working like they should (repeat start, hardware PEC, and all), and the ISR is working exactly as it should. Interesting to note, switching on the SMBUS bit only caused problems - couldn't run at 400khz, had to back it down to 100khz. Not sure if there's a register that could be tweaked for the SMBUS timing restrictions, but it works fine without (not using SMBalert pins, ARP, etc). And fyi, PEC can be used without having to set the SMBUS bit. I'll keep working on it (regular I2C, code cleanup, etc), things should go more smoothly from here on out. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105269 Sat, 08 Mar 2014 18:53:35 +0000 rp 105269@http://forums.leaflabs.com/ Argh! Got logged out before I posted, post lost... gbulmer - Thanks, and no problem - I like to type. ;) Yeah, I was pretty surprised to get a good look at the code and see it was just waiting around for the ISR to say it was done. I think of an ISR as like a thread in an OS, you should do what you need to in the ISR and let the system do whatever else it needs to do when the ISR is not running. Since the ISR may not fire, the actual function the ISR handles should be checked in the main code (ex, timeout) - at least, that's the way I'm building this. At the moment, it's still got wait_for_state_change, but that's just until I work out the details in the transactions and ISR (which is almost done). Right now, I could let go of wait_for_state_change and just poll for XFER_DONE from the main loop, but there's no timeout if it fails - yet. This'll be a function, returning something like "complete", "error / timeout", "busy", and if it times out, it'll stop whatever's in progress or pending, ready for a fresh message (ex, if timeout, can retry immediately or do other). At first glance, it seems USART is the same way. I'll likely change that to something to handle my PC to Control Board protocol, much like the I2C code - but it should be easier, less involved with serial comms from what I saw in the RM. I should mention - my 4 Maple Mini's have new brains, bootloaders loaded, ready to go. I tested my last version of PMBus / SMBus Tx w/ PEC (when the Maple Mini fried due to a bad ground before I could check the result), and IT WORKS. I called for a "margin down", and the converter did so (and it won't without proper PEC), no errors from I2C either. So, Tx with PEC is good. Rx needs to be adjusted, but I know where and how, so that's quick. Then, I'll work on the basic I2C transactions - essentially the same as what I have for PMBus / SMBus, but less. In all, I need to wrap some things up nice and neat, write in the transaction structures and functions to modify them (maybe with some Arduino-esque functions just to keep it newbie friendly). At the moment, the transactions live in the Setup of the test sketch (the hex is meaningless unless coupled with the "magic spreadsheet", will make more sense with functions to modify the transactions). To elaborate, a "transaction" (my term) is based on the firing of the ISR, incrementing through an array of uint32 on each firing (aside from the TXE / RXnE / BTF workaround mentioned earlier). Each uint32 is: 0->7 bits for data (rx or tx or Addr <<1 | R/w, if used), 8->15 bits are the expected low byte of SR1, 16+ are flags for actions performed within the ISR (ex, repeat start, set PEC, Send Stop, En ACK, Dis ACK, read SR2, Write DR, Read DR, etc). A transaction is the sequence of the expected SR1 state on ISR call, related data (in or out), and actions (single or multiple) to take. If the low byte of SR1 wasn't what was expected, something went wrong, bail. If the time between the last event (intialization of transfer OR ISR firing and expected low byte of SR1) and when the Status function is checked from the main loop exceeds some duration, all is cancelled / reset, and on it goes. Also good, I'm getting better with C. :) gbulmer on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105268 Sat, 08 Mar 2014 09:24:26 +0000 gbulmer 105268@http://forums.leaflabs.com/ rp - Thank you very much for sharing your experiments, progress and analysis. I hope you get it cracked, as I2C very useful. Polling instead of interrupts seems like a potential waste of significant CPU time; polling for the entire transfer of two bytes at 400KHz is almost 3000 instructions. Clearly, this is often acceptable as many I2C devices are very slow, but it seems irritating. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105267 Sat, 08 Mar 2014 06:59:53 +0000 rp 105267@http://forums.leaflabs.com/ It's pretty ugly, that's for sure. I read the errata - there are a few issues in there, mostly applying to "method 2", when I2C is not highest priority - which is OK in my case, as I need I2C as highest for PWM updates and timely IMU9150 reads (gyro correction of servo positions). I noticed the SMBus issue, can't nack a bad transaction - which isn't what the RM says (PEC, RM 26.3.8, "in reception" paragraph)!! I question if ST even knows how to make this thing work properly. I've looked over their CPAL libraries, and all I see from an external use standpoint is polling for state throughout the I2C transaction - not very useful, IMO - I must say, however, I didn't read very far into the CPAL code. But, one thing they didn't mention for the SMBus issue as a solution is to check the device's internal comm errors - no extra pins / protocols are needed for that. If the Rx (of the comm errors register) fails, one could safely assume communiction was bad and the originial command didn't go anyway. If the Rx succeeds (doesn't generate an error event), comm status in the device can be read back, with PEC at the STM32 indicating if the Rx was successful, then errors can be checked for. So there's another solution I didn't find in ST's documentation. Or, if I command a power off or voltage change, I should be able to read back the voltage to verify (which isn't a bad idea, regardless of NACK). I keep seeing a trend - in the libmaple code, in the ST examples - to disable the IRQs. To me, that just seems like a bad way to do things. Shouldn't the IRQs be left active, left alone to handle events as they occur? If the ISR fires, it's for a reason, right? I know it's a workaround for hardware problems, but I am trying NOT to do that (though the code includes a few "disable_irq" calls at the moment). What I found when disabling the ISR upon completion of a transaction was that I wasn't able to reset the last TXE / RXnE / BTF (though it seems they will go on forever), so enabling the ISR invoked TXE / RXnE / BTF on start of the next I2C transaction (sitting and waiting from the last event). So, what I did as a shortcut was to clear the TXE / RXnE / BTF and jump out of the ISR if I'm on the first "step" in the transaction and SR1 indicates something other than just SB. There's got to be a better way to handle this!! I'll keep beating on it, got a few days here to further things along. Meanwhile, I have a few Maple Mini's to repair, seems I had a loose ground that helped fry a few STM32's. Then, I can fix the loose ground, solder up some STM32F103CBT6's I got from Digikey yesterday, and get back to work on the code. At last test, I think I had tx nailed, but I won't know for certain until I have some Maple Mini's to work with again - I'm not willing to test on my custom board, I'd rather foul up a Maple Mini than the custom board!! Once the STM32's are soldered up, I'll need to reload the LeafLabs bootloader, which I've done before. Hopefully it won't take too long to clean up the pads (removed the chips Thurs) and get just enough paste on there to pin them down again. I know LL would be happy to have me buy more, but let's face it - cheaper to repair if possible - and it gives me more experience on reflowing chips in tight spaces. Of the code I'm working on, I'd be fine giving it to LL when done, but I haven't exactly followed their coding standards (spacing, 80 col, comment styles, etc). Thoroughly commented, though. I figure if they (or someone else) wants it bad enough, they'll work it over - which is a minor thing compared to the time I've spent messing with it!! I could go without PMBus to my DC to DC converters, but doing so limits some features I really want to implement, and requires me to forego intelligent shutdown of the system. It's a set of features I'd call "mandatory", so on I go. gbulmer on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105266 Thu, 06 Mar 2014 09:28:50 +0000 gbulmer 105266@http://forums.leaflabs.com/ rp - I2C on STM32F1xx seems to be the worst peripheral, and appears to have been changed in newer STM32 family members. Have you looked at the Errata: <a href="http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00190234.pdf" rel="nofollow">http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00190234.pdf</a> There are several errors noted, with some workarounds. It would be kind and helpful if mlundinse released code for the port of the logic analyser, even if it isn't as finished as they might like. (Full disclosure: I am not a member of LeafLabs staff.) rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105265 Wed, 05 Mar 2014 06:19:50 +0000 rp 105265@http://forums.leaflabs.com/ gbulmer - Ah, I thought you were wondering about the speed itself... :) Hmmmm... I read the thread, and you're right, there's no link to the port. Sure would be handy to have that code available. I wonder how much trouble it would be. I was staring at the $150 logic analyzer over on Sparkfun, wondering if it would be cost effective to just buy it vs spending the time to do something else. If mlundinse had posted the code, I'd surely try that first! What I'm finding out is that ST's implementation of I2C and their documentation leaves a lot to be desired. I'm fairly certain I'm not generating PEC on Tx (though I'm setting the PEC bit in CR1 after the TxE corresponding to the last byte sent - as the RM says to do). I'm guessing PEC is working on Rx, but I'm not entirely sure that it's even being transmitted by the DC to DC converter or received by the STM32. The ISR doesn't seem to be firing as expected for SMBus Tx, still trying to sort that out. What would be helpful is a block diagram of the I2C hardware internals, something more elaborate than what's in the RM - or a suitable write up on it. I'll keep plugging away at it, trying to figure out what ST is doing in there... Not sure what to do about analyzing the signals, though. Yo, mlundinse, got some code? :) gbulmer on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105264 Tue, 04 Mar 2014 11:03:58 +0000 gbulmer 105264@http://forums.leaflabs.com/ rp - at about 400KHz, you could experiment with using a Maple as a logic probe/analyzer. I remembered this thread: <a href="http://forums.leaflabs.com/topic.php?id=74071#post-104826" rel="nofollow">http://forums.leaflabs.com/topic.php?id=74071#post-104826</a> where mlundinse had ported the source of an Arduino logic analyser. I can't find a link pointing to the port, though. It probably isn't worth the effort unless the code is found, or you're very keen to have it work. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105263 Tue, 04 Mar 2014 06:55:22 +0000 rp 105263@http://forums.leaflabs.com/ gbulmer - Yup! Some math (this should be right): 6 bytes in this "read voltage" transaction (Addr, Cmd, Addr, RxByte, RxByte, PECByte). 400kHz, so 2.5 uS per cycle, meaning 2.5 uS per bit. The easy way, it's 5 bytes x 8 bits x 2.5 uS (if the start / ack / stop aren't counted) - 120 uS. So, about 140 uS means about 20uS left - start, stop, ack. 2 start, 6 ack (I think), 20 uS (8 * 2.5 uS). It was about 120 uS for 5 bytes (1 RxByte instead of two, just reading the version), so what I'm getting is consistent. Going through the math though, it seems like there's no code overhead - which isn't quite true, which makes me question the actual data stream (ex, am I actually generating a STOP, or am I signaling done before I even get the STOP?). So, more testing is needed before I can say yes, that's what it is. Seems to me it should be a bit longer... gbulmer on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270&page=2#post-105261 Mon, 03 Mar 2014 17:45:35 +0000 gbulmer 105261@http://forums.leaflabs.com/ rp - how fast is the I2C running, 400KHz? rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270#post-105259 Sun, 02 Mar 2014 20:52:09 +0000 rp 105259@http://forums.leaflabs.com/ More progress. Ran into trouble on doing a 2nd I2C xfer, found a workaround for now regarding RxNE and BTF that don't seem to obey STOP (not happy with it, but it'll work until I find a better solution). PEC timing seems correct, no PECERR. Got voltage readings off the 3 DC to DC converters, about 140 uS for each - and I'll have time between ISR calls to do other stuff as well. Things aren't quite the way I want them yet, but it's getting there - speed's decent. :) I really wish I had a DSO or Logic Analyzer right about now... rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270#post-105256 Tue, 25 Feb 2014 05:08:27 +0000 rp 105256@http://forums.leaflabs.com/ Well, things are a bit messy at the moment, but... Some SUCCESS!! Got the STM32 to read the version out of the DC to DC converter via PMBus using a repeat start. SR1 goes like this: 00000001 - Start Sent, send Addr (in transmit mode for 1 byte command). 10000010 - Addr Sent, TxE indicated (Master Tx, Rw = 0). Send data (1 command byte). 10000000 - TxE, 1 byte sent. Set Start (repeated Start!). 00000001 - Start Sent, send Addr (Master Rx, Rw = 1, read mode). 00000010 - Addr Sent, DR is empty (in receive mode at this point). 10000000 - 1st Byte Received. 10000000 - PEC Byte Received. ... And I was able to read in 10001, PMBus version 1.1, as I did from the Arduino, but by hardware I2C using the STM32. I should be able to put more polishing and testing in by the weekend. If I can do PMBus, basic I2C should go well also, as well as various PMBus send / receive msgs, etc. I don't think I'm setting the PEC bit at the right moment, but that's easy enough to fix. My intention is to run the MPU-9150 AND the DC to DC converters (3 of these) on the same I2C bus, which should not be a problem - you can mix the two, generally speaking. And yes, the ISR code is smaller. It should be portable to some extent, provided ST used the same basic approach to their peripherals. I looked in the RM at USART, seems to be much easier, looks like this method would work there as well if I need to change things. rp on "PMBus on STM32F103CBT6... ???" http://forums.leaflabs.com/topic.php?id=74270#post-105254 Sat, 22 Feb 2014 13:02:30 +0000 rp 105254@http://forums.leaflabs.com/ Info... The approach I'm using is a lot like a state machine / scripting mechanism, which makes sense to me for an I2C ISR. Basic flow goes like this: * Set Start (this sets things in motion). * The ISR fires until it has no more reasons to fire. * On each ISR run, there is an expected state for the lower byte of SR1. * If the lower byte of SR1 wasn't what was expected, something went wrong. * Along with expected state for each subsequent firing of the ISR, certain actions are taken, driven by configuration of a set of bits - en ack, dis ack, en pec, write dr, read dr, set done, etc. These actions in part help drive the state of SR1 for the next ISR call (if tx / rx / etc goes as expected). * Results (completion, data, etc) are checked for Done by a flag set when the ISR and related tx / rx / etc are done. If, for some reason, the ISR doesn't fire, checking Done will check for a Timeout condition and return appropriately. I don't know if I'm going to bother with the existing msgs thing, not sure if it'll matter in execution. In this approach, a transmission with repeat start is one "msg", "xfer", whatever. Not sure if I'll find that I'm waiting for I2C transactions to finish more than I'm waiting for I2C to be available for transactions - I'd expect that I'll spend more time waiting for it to finish while I process other things in my project. At first, I got hung up on events, thinking I needed to expect a certain event by configuration, but the reality is that the only important things that occur at the ISR are based on the lower byte of SR1. I have enough code to start testing as of last night, but I probably won't get to test it this weekend, life and whatnot. If I happen to find that the message templates I've built are wrong (expected state, actions, etc), that's OK, I'll be able to debug them easily based on whatever I see in SR1 when things go awry. Fixes at this point should be simple. There's a benefit to this approach, and that is that you can take advantage of all of the capabilities of the hardware - slave mode should also work with just a bit of effort, as well as 10 bit, hardware PEC, SMBus / PMBus, etc. Most of what I write (not C, btw) is configuration-driven, I'm a big believer in configuration-driven software. For the .Net patterns-and-practices-friendly, what I do is basically an altered / extended version of the command pattern. Extensible, reusable, minimal code, great performance - all good stuff. As for the I2C work, the end result will be a set of templates (extensible, basically arrays of uint32) modified by some helper routines - these will drive operation of I2C within the ISR. It may sound like a lot of code, but the code is actually pretty straightforward (more so than the current I2C stuff), and will likely be smaller than the original I2C code - itteration no more frequent than the ISR is called, same as what is in the current I2C code. Also, on figure 272, there's a typo - EV6 description regarding 10 bit master receiver, CR2 should be CR1. ** MPU-9150 - up to now, I've just been streaming raw data from it, and that's fine, will probably work for most of what I am trying to do, but there are a few features of "DMP" that I'd like to tap - I just have to dig through their examples enough to find what I'm looking for (ex, bump / tap reporting w/ direction).