read accelerometer(LIS302DL) on STM32F4DISCOVERY ?

[espruino-discuss2]

Posted at 2014-01-14 by JumJum

Is there a way to read acceleromter on STM32F4Discovery ?
I tried the example on http://www.espruino.com/LIS302DL,
but it always returns 0 for accx and accy on my board.
Checked it with Espruino version 1.45

[gfwilliams]

Posted at 2014-01-15 by @gfwilliams

What happens if you place your board is at an angle?

Just a thought, but could it be that an SPI1.setup with the correct mosi/mosi/sck pins is required?

[espruino-discuss2]

Posted at 2014-01-15 by JumJum

• placing the board in an angle does not change anything.
• Adding a line
  SPI1.setup({sck:A5, miso:A6, mosi:A7});
  did not change anything.
• On any call to read register I get back [0,0];
  for(var i = 0;i < 63; i++){console.log(i,SPI1.send([i+128,0], E3));}
• Adding a wait between each call did not change anything

BTW, testing same with SPI2 gives same result. Is there any way to recognize connected SPI devices ?

2ndBTW, dump returns this(and a lot of other lines)
SPI1.setup({sck:A5, miso:A6, mosi:A7});
pinMode(A6,input_pullup);
pinMode(B14,input_pullup);
digitalWrite(E3,1);
Where is B14 comin from ?

[gfwilliams]

Posted at 2014-01-15 by @gfwilliams

I'm not sure about B14 - it's because pin state is read from the device itself, so if it's set that way at reset (could be JTAG) that's what it thinks it should be.

could you try shorting A6 to A7 and typing SPI1.send("Hello")? That would help to check if SPI is actually working or not.

[espruino-discuss2]

Posted at 2014-01-15 by JumJum

• I used reset() and this command does not reset the hardware. So B14 was set by testing with SPI2 some time before.
• shorted A6 and A7 sent Hello and got back ="\x00\x00\x00\x00\x00"
• same with C2 and C3 and SPI2

[gfwilliams]

Posted at 2014-01-15 by @gfwilliams

Hmm. looks like an SPI problem on the F4 then. Sorry about that... Maybe you could try the 1v44 from the website? I did some SPI tweaks recently and I guess that could have somehow broken it.

[espruino-discuss2]

Posted at 2014-01-15 by JumJum

I checked with 1v44 and it works fine.
There must have been a change between 16th of dec and 18th of dec.
Nightly build from 16th works fine, from 18th it doesn't.
Hope this helps
Juergen

[gfwilliams]

Posted at 2014-01-16 by @gfwilliams

Thanks - yes, that's a huge help. 18th dec is a while ago.

Just made a bug for it: espruino/Espruino#181

Just a thought, but does it work if you specify a baud rate?

SPI1.setup({sck:A5, miso:A6, mosi:A7,baud:100000});

[espruino-discuss2]

Posted at 2014-01-16 by JumJum

I'm sorry, but the answer is no

[espruino-discuss2]

Posted at 2014-01-24 by user6350

I read the accelerometer on a STM32F4-DISCOVERY board.
I wanted to have 40 samples /s and I got 40 messages displayed on the Terminal screen, after accumulating data on a moving average process.

print("X= "+accx+" Y= "+accy+" Z= "+accz+" [16bit]" );

accv_start = setInterval(function () { print(getAcc()); }, 25); // 40 Hz
acc_stop = setInterval(function () { clearInterval(acc_start); print(console.log("ACC STOP"));}, 1000); // stop after a while

As expected the timer behavior was pretty deterministic , having a minimum timer resolution of 1 ms.
Now my question is :

Are you going to improve the timer's resolution , I say in example to 10 us, in a near future ?

[gfwilliams]

Posted at 2014-01-24 by @gfwilliams

The timer on the STM32F4 should be pretty good - to below 1us. The issue is the time that it takes to execute JavaScript code. Below 1ms, the JavaScript execution will be getting in the way of the timer.

You can however measure times using setWatch very accurately, as no JS is involved until after the event.

I'll be looking at increasing JS execution speed - there are many obvious ways to do it, but right now that is not actually a huge priority.

[espruino-discuss2]

Posted at 2014-02-13 by user6350

May it be that the new upgrade of version 1v51 introduced some bugs: with respect SPI and I2C programming ?

This works fine : Added Number.toFixed test056)

but this seems to haveSPI or I2C communications no longer working at leads on STm32F4Discovery.

Now use jshardware's SPI for SD filesystems - more multi platform.

Looking with a scope non signal is sent over the MOSI line, even clocks ar properly generated over the SCK line.
All serials are working fine.

[gfwilliams]

Posted at 2014-02-13 by @gfwilliams

Not sure I understand... So at that point, SPI stopped working - but it still sends clocks signals out?

How did it stop working - did you stop being able to receive data, or stop being able to send data?

[espruino-discuss2]

Posted at 2014-02-14 by user6350

I don't want to bother you with stupid problems, but…
something really unexpected is happening, at least on my STM32F4DISCOVERY board.

I checked on two different boards, the behavior was the same.
Then taking for grant a same board, I went back installing the past versions of Espruino.
When I installed version 1v41 the SPI behaved as expected.
Using later version I always got ZERO as output.
When I checked with the scope , seeing no data activity over theMISO , MOSI lines but correct clocks over the SCK line, I was using version 1v51.( my custom complilation )
The same wrong behavior happens with my backup versions: 1v48, 1v50.
I am going to look deeply at the code.
I noticed this behavior just now, because other functionalities gave no problems, so I proceeded installing new versions.

Is there a place in the code were I can easily and immediately check for ?

Of course the Javascript code was the same.
function onInit() {
SPI1.send([0x20,0b01000111], E3);
}

var avrx=0.0, avry=0.0;
function getAcc() {
var accx = SPI1.send([0xA9,0], E3)[1];
var accy = SPI1.send([0xAB,0], E3)[1];
if (accx>127) accx-=256;
if (accy>127) accy-=256;
avrx = 0.1accx + 0.9avrx;
avry = 0.1accy + 0.9avry;
console.log("X= "+avrx+" Y= "+avry);
}
onInit();

var t = setInterval(getAcc, 10);
// clearInterval(t);

X= 10.342832 Y= -1.9707
X= 10.308549 Y= -1.97363
X= 10.277694 Y= -2.076267
X= 10.249925 Y= -2.06864
X= 10.224932 Y= -2.061776
X= 10.302439 Y= -2.055598
X= 10.272195 Y= -2.050039
X= 10.244975 Y= -2.045035
X= 10.220478 Y= -2.140531
X= 10.29843 Y= -2.026478
X= 10.268587 Y= -2.02383
X= 10.241728 Y= -2.021447
X= 10.317555 Y= -2.019302
X= 10.2858 Y= -2.017372
X= 10.25722 Y= -2.015635
X= 10.331498 Y= -2.014071
X= 10.298348 Y= -2.012664
X= 10.268513 Y= -2.011398
X= 10.241662 Y= -2.010258
X= 10.217495 Y= -2.009232
X= 10.295746 Y= -2.008309

[gfwilliams]

Posted at 2014-02-14 by @gfwilliams

Do you ever call SPI1.setup({sck:..,mosi:...,miso...}) ?

On newer versions I guess it might not choose the right pins properly?

[espruino-discuss2]

Posted at 2014-02-15 by user6350

Same code.
Different behavior on two official Espruino versions. (STM32F4DISCOVERY)
1v41 OK
1v50 WRONG
I' ll have to check in detail the C code.
I am now going to check the I2C, too.
Any idea about what is going wrong ?

---

Attachments:

• screenshot_559.png
  
• screenshot_560.png
  
• screenshot_561.png
  
• screenshot_562.png

[espruino-discuss2]

Posted at 2014-02-15 by user6350

Excuse me I noticed the wrong usage of pin E3.

[espruino-discuss2]

Posted at 2014-02-15 by user6350

Not working.
It must be a reason for that ?

_____ _ | |_ ___ ___ _ ||___ ___ | | -| . | _| | | | | . | ||| || |||||_|
|| http://espruino.com 1v50 Copyright 2014 G.Williams

echo(0); X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0
=undefined X= 0 Y= 0

function onInit() {   SPI1.setup({ sck: A5, miso: A6, mosi: A7 , cs:
E3, int1: E0, int2:E1 } );   SPI1.send([0x20,0b01000111], E3); }

 var avrx=0.0, avry=0.0; function getAcc() {   var accx =
SPI1.send([0xA9,0], E3)[1];   var accy = SPI1.send([0xAB,0], E3)[1];  
 if (accx>127) accx-=256;   if (accy>127) accy-=256;   avrx = 0.1*accx
+ 0.9*avrx;   avry = 0.1*accy + 0.9*avry;   console.log("X= "+avrx+" Y= "+avry);    } onInit();

var t = setInterval(getAcc, 10); // clearInterval(t);

[espruino-discuss2]

Posted at 2014-02-15 by user6350

SPI1.setup({ baud:400000,  sck: A5, miso: A6, mosi: A7 , cs: E3, int1: E0, int2:E1 } );

Nothing changed at all.

[espruino-discuss2]

Posted at 2014-02-15 by user6350

I looked at the C code of the two versions 1v41 and 1v51.
Everything seems oK.
However, you now manage the SPI port using an interrupt and putting the data into a buffer before returning to the Javascript caller code.
May it be that
either
the interrupt is not generated ? ( Even NVIC structure seems programmed OK )
or
data is put in a wrong way or position into the 4 byte buffers ?
( conversion from unsigned char to int. !!! )
May it be that something the Head and Tail pointers disagree and some garbage is returned back… ?
Another difference with respect the 1v41 version is that now before sending data you do not flush the receiving SPI shift register to disregard eventual garbage.

I was not able to see any errors, but it is evident that something must now go wrong .
The ultimate solution is to DEBUG at C code level, the differences among the versions 1v41 and 1v51 being now known.

[espruino-discuss2]

Posted at 2014-02-16 by user6350

STM32F4 DISCOVERY and Version 1v51
Data is sent and received but ZERO is got from the Javascript side.

function onInit() {
  SPI1.setup({ mode:0, sck: A5, miso: A6, mosi: A7, cs: E3 } );
  SPI1.send([0x20,0b01000111], E3);
  getAcc();
}

var avrx=0.0, avry=0.0;
function getAcc(){
  var accx = SPI1.send([0xA9,0], E3)[1];
  var accy = SPI1.send([0xAB,0], E3)[1];
  if (accx>127) accx-=256; 
  if (accy>127) accy-=256;
  avrx = 0.1*accx + 0.9*avrx;
  avry = 0.1*accy + 0.9*avry;
  console.log("X= "+accx+" Y= "+accy);
  
}
onInit();

---

Attachments:

• IMGP0910.JPG

[gfwilliams]

Posted at 2014-02-16 by @gfwilliams

Thanks for doing that testing... I'll have to see what's up. The new irq-based code works fine on the Espruino board so I doubt it's anything very deep rooted in that. The strange thing is that 0s are being returned and not 255.

[espruino-discuss2]

Posted at 2014-02-17 by user6350

Really an hard to be logically fixed BUG.
The code is written properly.
I tested introducing inside the interrupt routine additional checks for the OVR or BSY flags but nothing changed.
I then thought about introducing a delay between reads in order to give the sensor enough time to compute results from a CS to the next , but nothing changed.
Interrupts are received in a proper way ( I measured 5 of them ) for the 1 write + 2 reads, but if ZERO is assigned instead of the first dummy 0x255 it "is likely" that this content is got from another SPIBuffer instead of the one addressed by the SPI port in use.
But looking at the code this cannot be…

Mah ???

[gfwilliams]

Posted at 2014-02-19 by @gfwilliams

Hmm. I don't get what changed. It's possible it's actually something on a more physical level - maybe the MISO pin is now not configured properly... I'll try and take a look at this...

[gfwilliams]

Posted at 2014-02-19 by @gfwilliams

Right, I just fixed this... The fix will be in 1v51.

[espruino-discuss2]

Posted at 2014-02-19 by user6350

Thanks a lot for your help.

Now the SPI works perfectly well, even I must check what you changed in order to have it working ( MISO pin ? ) and I immediately was able to get data from the accelerometer, but most important from the SD card.
It is to say that my last trouble was on the microSD card MISO pin.
I soldered by hand .5 mm wires on the rear of the small SMD card connector and by change the only poor contact was on the Card response (MISO) pin…
( I can say that Murphy law is really true )

Espruino is really a good design.
I can imagine what could be done when it will be ported to the powerful STm32F429 architecture.

---

Attachments:

• screenshot_566.png

[espruino-discuss2]

Posted at 2014-11-04 by trandi

Hi guys,
I don't know if anybody still follows this thread, but I'm having a very similar problem with the 1v70 on this same board.
The difference is that sometimes, after un-powering and re-connecting the board (most often I have to do it several times) I do get correct data.
BUT, as soon as I re-run the "SPI1.send([0x20,0b01000111], E3);" line I keep getting 0 OR 255 as values.

Thank you for your help,
Dan

[espruino-discuss2]

Posted at 2014-11-04 by trandi

Sorry guys, I've actually found the fix. One really need to add the SPI1.setup() line, and by trial and error I've discovered that the 3 below parameters are the mandatory ones:

SPI1.setup({sck:A5, miso:A6, mosi:A7});
SPI1.send([0x20,0b01000111], E3);

With them it works all the time, without it only works some times... (which is really strange :) )

[gfwilliams]

Posted at 2014-11-04 by @gfwilliams

That is a strange one... I'd have thought it would have defaulted to the lowest numbered SPI1 pins (which are the ones you've used).

By the way, you know that's shared with the MEMS sensor - so you have to be sure that it hasn't got enabled.