Unfortunately, I’m stucked at lower level, the SPI …

The low level libmaple spi.c/spi.h of F4 are quite obsolete compare to F1, so simply copy of SPI to F4 doesn’t work.
I don’t know which direction to go : waiting for F1/F4 merge, or should I investigate of if throwing away low level libmaple spi.c/spi.h of F4 and replacing it with the one from F1 should do the work ?
I don’t want to spent time for nothing … Any hint will be appreciated …
Unfortunately, I’m stucked at lower level, the SPI …

The low level libmaple spi.c/spi.h of F4 are quite obsolete compare to F1, so simply copy of SPI to F4 doesn’t work.
I don’t know which direction to go : waiting for F1/F4 merge, or should I investigate of if throwing away low level libmaple spi.c/spi.h of F4 and replacing it with the one from F1 should do the work ?
I don’t want to spent time for nothing … Any hint will be appreciated …
STM have some guides on conversion between the various processors, but I can’t remember if there is a F1 to F4.
Merging of F1 and F4 is a long term goal, but there are still issues that need to be resolved on the F1.
I’ve not looked at the SPI code on the F4, but I’m surprised if it was miles away from the F1 code.
I did some refactoring of the F1 SPI to bring it mostly up to date, and I recall Tim ( on the Arduino forum) making some changes as well, but nothing radical.
I’m pretty sure I just copied the latest AeroQuad code to my repo, but I don’t know when the AeroQuad team took their copy of libmaple and whether Leaflabs did much to the SPI in 2012 or 2013
However you can probably look at the dates on the AeroQuad GitHub repo and the Leaflabs libmaple repo and do some detective work.
You could also look at what Avik De did for his SPI in his repo Koduino, but he uses the HAL so the code will be a lot different ( but you could look at the HAL source files )
I will take a quick look at the SPI code this morning if I get chance, just to see the scale of the problem
Edit.
It looks like the AeroQuad guys don’t need SPI. I can’t see it in their repo at all
There appears to be low level code for SPI within the repo, but I’ve not had chance to diff it against the f1 code.
One telltail difference is the base address for the SPI register bank. If someone had updated this, then it shows someone has looked to porting to F4 (though doesnt mean they finished porting)
The SPI registers base address appears to be the same on both devices, so this is no guide to whether the files have been ported by AeroQuad
I’m not sure if this is correct either, but my understanding was that the F2 and F4 were similar. If so there is a migration guide from F1 to F2
(Not the AeroQuad guys use the F2 folders, which would suggest that F2 is a close relative to the F4. Personally I’d have renamed the folders )
I also found this on ST’s community forum
https://my.st.com/public/STe2ecommuniti … tviews=162
http://www.st.com/web/en/resource/techn … 033267.pdf
So basically, it looks like F2 and F4 are similar enough to assume code for the F2 generally works on the F4.
Also. While I remember.
I thought @mubase had I2S working on his F407, which is strange, as I2S is actually a enhanced version of SPI (and has nothing to do with I2C even though its name sounds very similar)
In which case… Perhaps we are closer to getting SPI working on the F4 that it seems.
and…
One other option. Someone could be cheeky and post an issue on the AeroQuad repo say that you’d like to use SPI with their repo, and see what response you get. As technically we are using their port,albeit a derivative.
I’ve also copied SPI library from F1 to F4, tweak it until it compiled. I’ved then add the SD library from Sparkfun, after some tweaking, I got it also compiled.
But unfortuntely, at runtime, the CPU is hanging during card.init() …

I will have to dig more, but I’m don’t have GDB to help me in Netduino2Plus environment, so printfs will still be my friends …

Can you commit the changes to your repo and send me a pull request
Re: SD Card
This may be a different issue. I know Victor PV has been working with the guy who maintains the SD card lib, and I think there may be a new cross platform version.
Perhaps you can PM Victor, as I’m not sure if he would read this thread as he doesn’t have a F4 board
Its an STM32F4 discovery. I got it for its audio and DSP capabilities.. I’ve got the I2S and codec working with the repo.. I had an STM32f429 with the tft but sold it on ….
I gave away my STM32F4DISCOVERY thinking it was a coretex M0.
Damn!
Also, I need to investigate further before doing a commit, first, because of the tons of #ifdef, I’m not even sure that the SPI is initialized using HardwareSPI, so maybe it get thru SoftSPI code which maybe still has some AVR registers manipulations.

Also, the SD library I’m using is maybe not adequate as you mentioned.
If so, I can try testing SPI on that board.
Now if I need to change a lot of stuff to just get a blink, I won’t probably get to test SPI soon, that’s why I ask if anyone has tested something in that MCU already.
I don’t know about F411, but it was pretty straight forward to get simple Blinker on my 2 boards with F405.
If so, if you could post your changes I can apply them to my local copy and go from there.
I’ve just try your SdFat, and it seems to stuck also during the init, as with the previous SD lib, so I presume it is something I didn’t do well in porting/copying the SPI files from F1 into the F4.
@Roger, So, since I don’t want to pollute my GitHub with unfinished work (with plenty of hacks to get it compile asap, such redundant #include/#define added), I’m better to simply upload a ZIP file at the root of my GitHub, https://github.com/martinayotte/Arduino … p?raw=true.
(BTW, as you warned me earlier, I had to port F1 some Stream/Print stuff into F4)
Thanks in advance for any helps,
It is more than changing the pin numbers in the macros.
Using the CubeMX I managed to map the Nucleo pins and find out that the Alternate function mapping is somewhat different. I found the Table 9 in the F104 datasheet, but not in any F103 datasheet. I have been searching to find the 9.4.2 AFIO_MAPR equivalent in the F401 references.
Searching for the macro names in AreoQuad they just code the numbers. There are nice macros in the F103 Nucleo folder. These are all hard coded to the F103. My plan is to define the F104 macro names in the board.h file as the other ones will just be ignored if not used.
The HAL generate stuff from the cube is not human readable.
This is the working F103 Nucleo init
void boardInit(void) {
afio_cfg_debug_ports(AFIO_DEBUG_SW_ONLY); // relase PC3 and PC5 on nucleo
afio_remap(AFIO_REMAP_USART3_PARTIAL); // remap Serial2(USART3)PB10/PB11
// to PC10/PC11 -> don't forget to insert into gpio.h:
// AFIO_REMAP_USART3_PARTIAL = AFIO_MAPR_USART3_REMAP_PARTIAL
afio_remap(AFIO_REMAP_TIM2_FULL); // better PWM compatibility
afio_remap(AFIO_REMAP_TIM3_PARTIAL);// better PWM compatibility
}
Anyway on the 103 if you look in board/board.cpp (in any of the variants)
They have an enum to handle the port / pin numbers
/* Pin aliases: these give the GPIO port/bit for each pin as an
* enum. These are optional, but recommended. They make it easier to
* write code using low-level GPIO functionality. */
enum {
PA0,PA1,PA2,PA3,PA4,PA5,PA6,PA7,PA8,PA9,PA10,PA11,PA12,PA13,PA14,PA15,
PB0,PB1,PB2,PB3,PB4,PB5,PB6,PB7,PB8,PB9,PB10,PB11,PB12,PB13,PB14,PB15,
PC0,PC1,PC2,PC3,PC4,PC5,PC6,PC7,PC8,PC9,PC10,PC11,PC12,PC13,PC14,PC15,
PD0,PD1,PD2
};/* Note PB2 is skipped as this is Boot1 and is not going to be much use as its likely to be pulled permanently low */
However, looking at the amount of hassle that Matthias had with his Nucleo F103RB and you appear to be having with your F4 Nucleo, it makes my Discovery F407 look like childsplay
I’d love to spend more time on the F4, but we are still having some core issues with things like interrupt vector tables
But I think I’ll get around to it in the end.

So, the SPI lib is really where I should continue investigation …

Edit : I’ve try to use instead the HardwareSPI in libmaple as standalone with the FX2 logic capture, and it works !
So, I have to figure out the differences between both libs (or trying to make SD works with that HardwareSPI) …
But it’s the hardware SPI for the F1 and there may be differences between F1 and F4
Your best option may be to what I did and simply repurpose / rename the hardware SPI class (but using the F4 version)
All you ever learn with arduino is copy paste, no under you guys are totally in the dark … just read the damn STMF4 atasheet !
Is this a new kind of spam… they run in, tell you that you can’t code, and throw the datasheet, and run away!
Roger, looks like there is a hole in the screen wire on the backdoor.
… any of you ever done…
Butchered the English language… even Google Translate would not make that error.
Maybe new members only by invitation? Yea, silly, I know… I guess that is why cars have horns is so you can get the driver’s attention as you wave the middle digit.
Ray
I’ll investigate
It appears to be possible to post without registering, just by answering the question.
This seems like a big flaw in PHPBB, which I’m suprised is the the default install !
I’ll definitely need to turn it off.
This seems like a big flaw in PHPBB, which I’m suprised is the the default install !
Ah, that is the U.S. government default security setting …
Ray

@Roger, I’ve got the HardwareSPI compiled with plain SD, but unfortunately, I’m out of luck these days : it fails again in cardCommand(CMD0) !
(BTW, looking if there was differences for HardwareSPI between F1 and F4, I see that there is no such under F1, so it is a bit difficult to compare …
I don’t have much clues : I think I will have to try it under my MapleMini, hookup again my FX2 logic capture and compare it with the F4 …
OK. I think I’ve fixed that issue.
I’m not quite sure how, but I had set the forum so some sections (those under the Boards sub section), has assigned “Standard Access” to Guests.
Which meant they could post.
I’m not sure when this happened, probably some time ago, as I recall noticing that the post reply button was visible when I was not logged in, but I was busy at the time and ignored.
So I don’t think this was actually a hack.
Anyway, PAU was a guest, who obviously knows how to answer questions on the Arduino.
I will see if I can retrieve PAU’s IP Address and get their location.
I’ve downloaded the web logs and I’ve isolated all the IP address of anyone that has posted to this thread.
I just need to cross reference against the known users and then we have PAU’s IP address and also lots of great information that their browser has shared to the server
I think I have isolated the IP address that posted.
Please PM me if you want it.
You can get the original hardware SPI file from my repo, by looking at the second commit, when I initially added the files.
BTW. I’m not sure if this is the issue you are having, but it looks like NSS (hardware chip select) doesn’t work, and whats worse is that it seems to override the GPIO config for PA4 (on F103) for use as chip Select )
I recall that its a known issue that NSS didnt work with LibMaple, but most people didn’t care as they didn’t want to be restricted to using PA4 as SS (aka CS).
On AVR there isn’t an equivalent to NSS, and CS is always done using GPIO by the lib’s, Its not handled by the SPI lib, it’s normally handled by the libs that use SPI (or sometimes its just handled by the sketch).
Anyway, if you are using PA4 (or the equivalent pin on the F4, – I”m not sure which pin is NSS on the F4), you could try just pulling CS permanently low, or use another pin.
I’ve found the SD lib works fine now that I have moved the pin (and when I pull it low permanently)
That was it, although I don’t completely understand the NSS issue.
I thought NSS and CS was the same pin, so reading the other thread and your reply above, I decided to change the #define BOARD_SPI3B_NSS_PIN in discovery_f4.h to a different pin than the actual CS on Netduino, and SD lib start working since I’ve initialized the CS pin myself.
So, it is now a step further !

Next challenge is to try the ENC28J60 with the same method and try to get the networking running.

This sounds like the same bug on both processors
I will sort out a fix on F1 and let you know what needs to change on the F4
I presume that the real fix need to be done at the lowest level as possible to avoid having to do pinMode() on every libraries which are calling begin().
So, maybe it should be done in the begin() itself ?
Yes. I intended to put the fix in SPI.begin()
Actually I could put it in the spi init low level functions called by begin() but I need to work out the best location to put this so it doesnt keep getting called multiple times during the setup process