Bootloader issue(remapping SPI) ***SOLVED!***

[curt2go]

Ok. So generally I have complex issues when I ask you guys for help and this one is no different. So I will try to explain the best I can.

compiler 5.067
Chip 24ep256gp206

I am using the Brush SD bootloader. And by the way if you are on the fence about his stuff, don't be. Best support out there!

The bootloader is working fine. I know this because I can load an old version of my program and everything works fine. So all the config bits and everything is all good. The problem started when I decided to use the SPI to do multiple things. When I am not reading the SD with the SPI, I remap it and use it to output bits to something else actually using a DMA to do it. It works very good.

I also know the new program works fine because I can load it on with an ICD3 and it works like a charm.

I also know that the rest of my program after bootloading it on works fine.

Its only the SD card and the SPI2 I am having issues with.
The program initializes the SPI for the SD card at the start, and then it tries to initialize the SD card. But the issue is i am not getting any data out. Clock is working, CS line is working but no data (Watching with logic analyzer). I have tried remapping the pins right before looking at the SD card for the first time but to no avail.
I am using a Bluetooth output to see all registers before I go to the SD card initialization routine and they are all set the same.

Each time I try it first with the ICD3 to make sure the code works properly before trying it with the bootloader.

I am wondering if anyone has any insight. I know you will probably need more info so let me know. Any help would be great. I've been trying to figure this issue out for way too long. Brush Electronics has been helping me out along the way as well.

[Ttelmah]

Obvious thing. You have got IOL1WAY disabled?.
Needs to be, or your code can't change the select setups after the
bootloader has set them.

[curt2go]

Obvious is good. But yes. Disabled both on the bootloader and the App code.

That being said, even if it was not set, I am not remapping until after I had done my initial SD card connection on my APP. Or would it matter? Because the initial setting from the bootloader would be the SD card pins.

Can I see config bits at run time? I have never had any reason to in the past. I could verify that.

[Ttelmah]

Yes it would matter.
The setup is done at the start of the code, so the bootloader will be setting
the peripheral to it's settings, before the 'main' code is reached.

Setting fuses in the 'main' code is pointless. The fuses the code has
are those set by the bootloader. The main code can't change the fuses
or the bootloader won't work. This is why it is actually 'tidier' to just
copy the bootloader fuse settings into the top of the main code as a
set of remarks, and have it's fuses set as:

#FUSES NONE

Yes, you can read the configuration fuses look at the function

read_configuration_memory

You need a RAM buffer large enough to hold all the fuses, and
specify to read this many entries, and you can then see exactly
what the chip is using. Compare with the values at the end of the
listing files (all the fuse settings are here).

[curt2go]

I know that the fuses can't be reset. My point was that the bootloader is an SD card bootloader and it was reading the SD card already. I am not remapping the pins at the start of my code, so that is what I meant when I said maybe it does not matter, as it was already setup to read the SD card.

I will have a look at the config bits. Thank you for the input so far.

[Ttelmah]

OK.

In which case, look at sequencing.
First thing SD technically requires it's first transaction at a slow rate,
and then switches to faster operation. Is it possible the initial slow
rate is not happening after the bootloader?.
Then, after initial power on, the SD card will be in the IDLE state.
If the bootloader talks to it, it'll no longer be in this state. The main
code driver may need to send a GO_IDLE command to put the card
back into the state that it expects to start from.
Obviously also look at the signal sequencing.

[curt2go]

That is true, but I can see on the logic analyzer that the SDO pin on my side is not sending any data. So clock speed won’t matter. But I am doing all the SD card inits correct as my code from before I started using the he pin remapping worked when bootloader and that is the same code.

I also tried using a getenv (SPI2_DO) to get the pin at runtime but the command is not working as it gives a weird pin, I also did the SCK and DI and they gave me wrong pins and I can see they are the right ones on the logic analyzer. I will still take a look at your suggestions, I appreciate all the input.

[curt2go]

Well, well, well.

It was a compiler issue. Not sure exactly what, but I bought the newest verison, I was on 5.061 and the 5.083 works fine with the bootloader.

Thanks for the input.