2012-11-30 07:43 AM
Hello ST!
We are using the L6470 and it is working quite well. But: We have problems when reading the ABS_POS register. It seems to be that the 8th Bit (for 128) is always Low. See Our values:
Go To Pos Returned values
127 127
128 0
129 1
255 127
256 256
383 383
384 256
385 257
and so on. seems that the 8th bit (of 22) for the value 128 is always low.Is this a common issue? Does anyone have this problem too?How to slove this?Thanks! #l6470 #l6470-abs_pos2012-12-04 07:35 AM
Hello,
The ABS_POS register is a 22 bit up/down counter and all the bits are used. Please check the SPI signal in order to verify if the communication is correctly performed (timings, levels, etc).Kind RegardsEnrico2013-05-23 06:23 AM
I have a very similar problem, the ABS_POS is missing 128 steps for some ranges.
I start at ABS_POS=0I go to absolute position 1000 : ABS_POS now says 872 (1000-128)I go to absolute position 2000 : ABS_POS now says 1872 (2000-128)I go to absolute position 3000 : ABS_POS now says 2872 (3000-128)I go to absolute position 4000 : ABS_POS now says 3872 (4000-128)I go to absolute position 5000 : ABS_POS now says 4872 (5000-128)I go to absolute position 6000 : ABS_POS now says 6000I go to absolute position 7000 : ABS_POS now says 7000Cheers,Mike2013-06-24 02:03 PM
I too have the same issue except the 8th bit for both the acceleration and deceleration registers is held low. This means the reset value of 0x08A reads 0x00A. All written values which require bit 8 read back incorrectly. Those that don't read back fine. My SPI communication subroutine successfully reads all other registers. Moreover, I've examined the SPI bus via an oscilloscope and see no timing problems.
I'm using EVAL6470H. The visible text on the L6470:7B524L6470HPHL 2222013-08-12 08:27 PM
Dear forum, I ran into exactly this problem. L6470 is perfectly capable of sending the MSB of a byte in SPI reply (and my uC can receive it and give it to me), but on the reply to ABS_POS, it consistently drops the MSB. If I set ABS_POS to 0xFF and read it right back, I get back 0x7F. If I set ABS_POS to 0x3FFFFF (that is, -1) and read back ABS_POS, I get back 0x3F7F7F.
Please see the 2 cases (when ST sent 0xFC for the upper byte of the status register, vs. when I get back 0x7F for the 2nd byte of the ABS_POS) for the comparison of the working and not working case. I am seeing this on the L6470 that came with EVAL6470H eval board, if that makes any difference. Not being able to read the current position really *****, since there is no guarantee that L6470 WILL deassert the nFLAG pin with STEP_LOSS (A or B) when it loses step. It would be really nice to solve this problem. Thank you for your kind advice. ________________ Attachments : 0x7F.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzJ4&d=%2Fa%2F0X0000000bJa%2FgQ3DchAQsoKUEsA_VsxzFCMfAg7rlns7gS7gVBO1olk&asPdf=false0xFC.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzIu&d=%2Fa%2F0X0000000bJZ%2FuHG6r1TZv1kRIqkyU06dQZj_snNk3UD9TgNHTgZcUMY&asPdf=false2013-08-14 12:30 AM
Dear Henry Choi,
The SPI is not properly configured. As described in figure 18 of the datasheet the dSPIN uses a POL=1 PHA=1 SPI configuration (see attachment). When the CS is forced low, the clock signal must be high. The SDO is updated at CK falling edge and it must be read by the MCU at CK rising edge. Please, change the SPI configuration and check if the issue is still present. Regards Enrico EDIT: For the support on the motor control devices, please use the respective section of the forum:/public/STe2ecommunities/motordriver_ics/Lists/Motor%20Driver%20ICs%20and%20Boards/AllItems.aspx
________________ Attachments : Figure_18.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyuB&d=%2Fa%2F0X0000000bJX%2FPeK6RcNU0ZKzxNOAPtBT1CfHpbhwG02cFki8EZkpZzg&asPdf=false2013-08-14 09:46 AM
Thanks Enrico, POL = 1 and PHA = 1 did NOT work (could not even get the status register), but we solved the problem by changing from (POL = 0, PHA = 1 to POL =1, PHA = 0). According to the TI and ST documentation, this should NOT work. On TI document slau049f.pdf page 294 the definition of the bits:
CKPH Bit 7 Clock phase select. Controls the phase of UCLK.0 Normal UCLK clocking scheme1 UCLK is delayed by one half cycleCKPL Bit 6 Clock polarity select0 The inactive level is low; data is output with the rising edge of UCLK;input data is latched with the falling edge of UCLK.1 The inactive level is high; data is output with the falling edge ofUCLK; input data is latched with the rising edge of UCLK.On ST L6470 datasheet page 38:The SDI is sampled on the rising edges of the CK. ... The SDO is latched on the falling edges of the CK.As as you can see, it should NOT work, but it does anyway.2014-07-06 10:12 PM
Hi forum,
I have to take back my prior post. I was able to get my TI LaunchPad boards to communicate with the L6470 with losing the high order bits. The setting that works is:legacy Freescale, 5 mhz inverted clock, MOSI phase delayed 1/2 clock cycle, 8 bit framing. This also works in a daisy-chain configuration.So, I guess the only problem with the unusual configuration is that I can't add LS7366R quadrature counters to the same SPI bus.Regards,Bob Rice