English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 18 August 2014, 17:59   #1
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
Question Minimig PIC1826K20 help needed (solved!)

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?

Last edited by Mathesar; 22 August 2014 at 12:14. Reason: Issue has been solved
Mathesar is offline  
Old 18 August 2014, 18:08   #2
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
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
Attached Files
File Type: zip PIC18F26K20_Minimig.zip (66.0 KB, 155 views)
Mathesar is offline  
Old 18 August 2014, 18:13   #3
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
forgot to attach:

Here is the tiny bootloader for the PIC18F26K20

Mathesar
Attached Files
File Type: zip tinybldr_PIC18F26K20_intrc_115K2.zip (2.7 KB, 149 views)
Mathesar is offline  
Old 18 August 2014, 19:32   #4
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,997
Good looking work. is this pic a 1:1 replacement for the original. I would like to try to help debug.
alexh is offline  
Old 18 August 2014, 19:36   #5
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
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 is offline  
Old 18 August 2014, 19:42   #6
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
If you want to compile the code for use with the bootloader, use these settings for the XC8 linker (rom ranges)

Mathesar
Attached Thumbnails
Click image for larger version

Name:	Nieuwe afbeelding (1).jpg
Views:	242
Size:	68.2 KB
ID:	41096  
Mathesar is offline  
Old 18 August 2014, 22:43   #7
Stedy
Registered User

Stedy's Avatar
 
Join Date: Jan 2008
Location: United Kingdom
Age: 44
Posts: 726
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)?
Stedy is offline  
Old 19 August 2014, 17:01   #8
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
Quote:
Originally Posted by Stedy View Post
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 is offline  
Old 20 August 2014, 22:00   #9
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
Thumbs up

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!
Mathesar is offline  
Old 20 August 2014, 23:05   #10
Stedy
Registered User

Stedy's Avatar
 
Join Date: Jan 2008
Location: United Kingdom
Age: 44
Posts: 726
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
Stedy is offline  
Old 22 August 2014, 06:55   #11
modrobert
old bearded fool

modrobert's Avatar
 
Join Date: Jan 2010
Location: Bangkok
Age: 54
Posts: 637
Found some interesting suggestions in this forum thread.

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


Specifically this part.

Quote:
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).
modrobert is offline  
Old 22 August 2014, 09:47   #12
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
Solved

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
Mathesar is offline  
Old 22 August 2014, 13:18   #13
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,997
Looking forward to it.

Quote:
Originally Posted by Mathesar View Post
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 ?

Quote:
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

Last edited by alexh; 22 August 2014 at 13:23.
alexh is offline  
Old 22 August 2014, 21:02   #14
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
Quote:
Originally Posted by alexh View Post
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.

Last edited by Mathesar; 22 August 2014 at 21:11.
Mathesar is offline  
Old 26 August 2014, 10:44   #15
Mathesar
Registered User

Mathesar's Avatar
 
Join Date: Aug 2014
Location: Netherlands
Posts: 557
KGL140824 released

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
Mathesar is offline  
Old 12 September 2014, 12:56   #16
Solo761
Registered User
 
Join Date: Aug 2013
Location: Croatia
Age: 41
Posts: 341
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.
Solo761 is offline  
Old 12 September 2014, 13:24   #17
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,997
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?

Last edited by alexh; 12 September 2014 at 15:06.
alexh is offline  
Old 12 September 2014, 16:48   #18
Solo761
Registered User
 
Join Date: Aug 2013
Location: Croatia
Age: 41
Posts: 341
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
Solo761 is offline  
Old 12 September 2014, 18:33   #19
FOL
PSPUAE DEV

FOL's Avatar
 
Join Date: Nov 2006
Location: Barry / UK
Age: 43
Posts: 5,909
Send a message via MSN to FOL
Quote:
Originally Posted by alexh View Post
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.
FOL is offline  
Old 12 September 2014, 19:08   #20
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,997
Quote:
Originally Posted by FOL View Post
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
alexh is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help needed with Cannon Fodder HD on Minimig Gaula92 support.Games 28 17 August 2011 18:08
I am after a MiniMig Vars191 MarketPlace 5 14 March 2011 23:38
MiniMig Repair (needed INFO) Zetr0 Hardware pics 9 29 March 2010 07:56
My New Minimig Kitty support.Hardware 2 04 November 2009 16:54
minimig jimbob005 Amiga scene 11 30 May 2008 09:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.09746 seconds with 16 queries