Minimig PIC1826K20 help needed

[Mathesar]

Hi All,

I have been working on a port of Goran Ljubojevic's excellent PIC firmware for the Minimig to the PIC18F26K20. The port is based upon PGL100818 from google code.

The PIC18F26K20 is 3 times as fast, has much more ram and twice as much flash as the original PIC.

The new firmware now supports 16MHz SPI bus speed, multiple read/write commands to the HDF and is generally much more responsive. I have also added HDF indexing and a more efficient fileseek() function.

From power on to kickstart screen takes about 8 seconds on a class-4 SDHC card. Faster cards boot even faster.
Booting WB68Lite from a 1Gb HDF takes about 12 seconds .
All in all a good upgrade from the original PIC for Minimig owners on a budget (the PIC18F26K20 costs a few euros).

The port is finished but one bug remains and I am pulling my hair out on how to solve this: HDf writes get stuck or corrupt the hardfile.

The scenario:
I have created a 1gb HDF with stock WB68K lite loaded. maxtransfer properly set to 0x1fe00. The SDHC card is a kingston class-4 4Gb card.
The FPGA core is FSB131020(42MHz).
CPU is turbo (42MHz), Kick 3.1, 1mb chip, 0.5mb fast. SPIMOD on board is done.

I load up dirpopus and copy the folder programs to my-files.
Then, somewhere, the copy operation hangs. The drive led stays on and through the debug console I can see that the PIC executes read or multiple-read commands endlessly.

The strange part is that it only happens with the SPI bus is set to 16MHz. On 4MHz everything goes fine. Also when, i add a small delay after each read or write command (10..20ms) everything goes fine as well. Even on 16MHz.

So, I am really puzzled. I have tried to mimic the behaviour of the ARM version as much as possible. I suspect a timing problem as adding delays or changing the SPI speed changes things. But where?

Can anyone help me?

[Mathesar]

Here is my firmware so far.

It compiles under MPLAB.x with the XC8 compiler. I have the compiler set to PRO (using evaluation period). Remember to reserve about 256 bytes at the top of the memory for use with Tiny bootloader.

To load the file into the PIC you can use Tiny Bootloader with the attached bootloader.

Mathesar

[Mathesar]

forgot to attach:

Here is the tiny bootloader for the PIC18F26K20

Mathesar

[alexh]

Good looking work. is this pic a 1:1 replacement for the original. I would like to try to help debug.

[Mathesar]

Yes, it is a 1:1 replacement. There are no modifications on the Minimig board necessary. The SPI-mod must be done however to use the 16MHz SPI mode. Without the SPI-mod done you can't go faster than 4MHz.

Glad that you want to help

Mathesar

[Mathesar]

If you want to compile the code for use with the bootloader, use these settings for the XC8 linker (rom ranges)

Mathesar

[Stedy]

Hi,

It sounds like you've got a settling issue with the SPI port. I've seen this before. One workaround is to add an assembler NOP instruction or two around the SPI access routine, this give more time for the signals to settle.

Taking a quick look at the code and datasheet, try changing the SLRCON register back to the reset default of 0x7. If you have an oscilloscope, measure the SPI port signals.

I'm not familiar with this specific PIC18 variant but I know the pain of seemingly working device init code and the oddities that ensue.

Do you have a PIC debugger (Pickit or ICD)?

[Mathesar]

Originally Posted by Stedy

Hi,

It sounds like you've got a settling issue with the SPI port. I've seen this before. One workaround is to add an assembler NOP instruction or two around the SPI access routine, this give more time for the signals to settle.

Taking a quick look at the code and datasheet, try changing the SLRCON register back to the reset default of 0x7. If you have an oscilloscope, measure the SPI port signals.

I'm not familiar with this specific PIC18 variant but I know the pain of seemingly working device init code and the oddities that ensue.

Do you have a PIC debugger (Pickit or ICD)?

I will try your suggestion. Settting the SLRCON back to 0x07 will make the SPI pins slower right? Doesn't that make the 16MHz SPI mode more likely to give problems?

I had a lot of trouble getting the SPI to work. I had to replace all direct writes to SSPBUF with the SPI() function. The SPI module on the K-series of the PIC18 works differently than on previous PIC18's. If you don't read from SSPBUF, the previous value will not be overwritten with new read values. This took me a while to figure out .

Also, a lot of things actually go right on 16Mhz, loading kickstart, booting workbench, loading files/programs, etc, etc. Also floppy emulation goes fine. Only copying of files on the HDF goes wrong sometimes...

I have a scope BTW so I will try your suggestion and have a look at the SPI signals.

[Mathesar]

I have tried to set SLRCON back to 0x07. It didn't work. The signals on the SPI bus became so slow that even kickstart refused to load.

I did however discover something else... When the PIC is endlessly executing ATA read commands the selection of ADF files gets broken too.
Also, a simple reboot of the Amiga side of the Minimig doesn't resolve the issue. I didn't notice this before as I would normally hit the reset button, resetting both the Amiga side and the PIC side.

So, it seems something in the PIC code OR in the SD-card itself gets upset .
Tommorow I will investigate further. To be continued!

[Stedy]

Hi,

Interesting find on the reset operation.

The SLRCON register was worth a shot, just in case it was marginal timing.

A couple of questions that may help narrow down the problem.
1) Have you tried different speed or brand SD card?
2) If you do not use the HDF support and only use ADFs, does the problem still occur?
3) Have you checked the silicon errata for the PIC?

Keep debugging,

Ian

[modrobert]

Found some interesting suggestions in this forum thread.

http://www.microchip.com/forums/m420176.aspx


Specifically this part.

I bet that very few people are aware of the certainly useful slew rate control and its unexpected impact when SPI is supposed to run at frequencies higher than about 1 MHz. The attainable frequency is, of course, strictly depending on the (mainly capacitive) load to be driven. One of my customers experienced a frequency of appr. 1 MHz as the maximum. Only after he adjusted the slew rate he did reach the speed of 16 MHz.

I wished Microchip would put sort of a warning note in the data sheet's SPI-chapter (and all other relevant chapters as well).

[Mathesar]

I have found it!

It had nothing to do with SPI after all. But, Stedy's suggestion to change SLRCON did somehow made me discover the real issue.

It was an SD card write timeout!

Here is how I discovered it: Once I figured out that the ADF part of the firmware also stopped working and that a reset of the Amiga side of the system didn't resolve the issue I turned my attention to the SD card code.
I turned on debugging in mmc.h and guess what: lots of errors being reported

Apperently, the first error that occurs is a write operation timeout; after that the firmware tries to do some read commands that fail immediately causing the endless read operations. The PIC firmware doesn't report failed SD card commands as failed ATA commands to the Amiga side so everythings seems to go OK while in reality it doesn't.

The write timeout in the original firmare is realized by counting the number of iterations in a loop. As the new PIC runs three times as fast the timeout counter also expires 3 times as fast. The SD card thus gets not enough time to complete the write operation and the system goes haywire.

I knew of some other busyloops that were used as timeouts and I had already fixed them but I overlooked this one.

I now replaced all timeout code in mmc.c (and other parts of the code) by code that uses the proper timer functions. I also increased the write timeout to 500ms(!). I found some SD specs that state that SD card can take up to 250ms or 500ms to complete a write operation in some circumstances. Normally it takes much less of course. You can find these specs here:
https://www.sdcard.org/downloads/pls.../part1_410.pdf
(see paragraph 4.6.2) I think the timeout in the original PIC version was marginal as well.

I now cannot get the system to fail; copies, installs, write operations, everything works perfect! And very snappy compared to the original version Almost like a sort of mini-ARM version .

I want to do some final things now (like bigger fonts, alternate core loading, some cleanups) and then it is ready for release!

Thanks for all your suggestions,

Mathesar

[alexh]

Looking forward to it.

Originally Posted by Mathesar

The SPI-mod must be done however to use the 16MHz SPI mode. Without the SPI-mod done you can't go faster than 4MHz.

Where can I read about the 16MHz SPI change?

Is it this ?

Originally Posted by jaqube

Bypassing R51 is necessary to get the SPI clock running at 24 MHz (SD and SDHC cards) or 16 MHz (MMC) instead of nominal 8 MHz. It speeds up hardfile transfer rate by about 20% (380 KB/s w/o and 460 KB/s w/ the mod and the CPU in turbo mode - w/o the mod and running the CPU @ 7 MHz the transfer speed is 240 KB/s). The easiest way is to short pads of resistors R50-R51

[Mathesar]

Originally Posted by alexh

Looking forward to it.


Where can I read about the 16MHz SPI change?

Is it this ?

Yes, this is it. I must note that even on 4MHz the new PIC is quite fast. You can select either 4MHz or 16MHz using the OSD menu. for 4MHz no modifications are necessary.

The difference between the old PIC and the new PIC is much greater than the difference between 4MHz and 16MHz. In fact; booting, loading files, etc is barely faster on 16MHz.

The bottleneck in the old PIC for handling HDF's was fileseek, not the raw transfer speed. Because the new PIC has more RAM I could implement indexed fileseeking which speeds up HDF access tremendously, just like the ARM version.

[Mathesar]

The first version of the PIC18F26K20 firmware is released.
You can find it here:
http://www.minimig.net/viewtopic.php?f=5&t=627

Enjoy!

Mathesar

[Solo761]

Great work! Finally flashed one 18F26K20 with this firmware, so far so good, works without problems. I still have to try HDD part, haven't tried it before as I have standard minimig 1.1 with 2MB ram so WHDLoad is out.

I've noticed on minimig forum that you said new update could have better compatibility with games like Darkmere. Would Lotus III Ultimate Challenge be one of these games? Haven't played much with my minimig, but I've noticed that this game doesn't work, 1 and 2 work fine, but this one, after loader is set stays on black screen. It did so with original PIC so it's not an issue with your firmware port.

[alexh]

Mine too is a standard one with 1.5Mbytes of usable RAM (Remember that Kickstart takes up some RAM)

Been meaning to update it. What do I need? Just 2x SRAM chips and some solder?

[Solo761]

I've also been looking at ram upgrade, here's what I found

http://www.minimig.net/yaqube/ramexp/ramexp.html

Not that hard to do, but it won't be so easy to find chips

[FOL]

Originally Posted by alexh

Mine too is a standard one with 1.5Mbytes of usable RAM (Remember that Kickstart takes up some RAM)

Been meaning to update it. What do I need? Just 2x SRAM chips and some solder?

We offer this upgrade as a service, including chips.

[alexh]

Originally Posted by FOL

We offer this upgrade as a service, including chips.

Interesting...

Could you include a programmed PIC 18F26K20-I/SP (I think that's the right one) with TinyBootloader & the new firmware from Mathesar?

I think they RRP about £2? You can even keep the old PIC