Wanted: STK525 User

Go To Last Post
54 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Freaks,

I'm looking for an owner of a STK525 USB board, and at least *two* different USB flash disks (of any size, description, capacity, etc) to do a little testing.

My latest MyUSB internal code has a problem, in that on a STK525 user's board the system doesn't seem to enumerate a second, different USB disk on the first try. I've got a USBKEY board and have no such problems, which gives me the familiar conundrum of developers - how to debug a problem I can't see?

All I need a STK525 owner is for them to load in a HEX file I give them, insert one USB flash disk, remove it, insert another flash disk and see if the system locks up - either by the LEDs or via a serial terminal. Doing so will narrow down the cause of the problem.

If anyone's interested in helping out my open-source project in this manner, please reply here.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Last Edited: Tue. Jan 29, 2008 - 01:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're talking about an STK525, are you?

Well, I already promised you once and didn't keep my promise...
but I could try again.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,

I don't know if it's any use to you but when he was here the other day my Atmel FAE gave me an STK526 so I could have a "USB play". Are you sure you meant "501" as I thought that was jus the carrier for the QFPs such as the 64 and 128? When I had a 501 (I had to give it to someone else) I'm pretty sure it didn't have anything "USB" about it.

Cliff

PS the only problem I may face is that the kit has two AT90USB162's which are notoriously not supported correctly in several of the C compilers (because they don't have MUL and the assumption has been made that they do - this has necessitated the recent inclusion of AVR3.5 architecture in GCC for example)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whoops! I mean the STK525 (not the STK526 - MyUSB doesn't currently support the AT90USB162 or AT90USB82) rather than the STK501. I'll fix the topic title now.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, I ordered a STK525 and it should arrive Friday. Send to me whatever tests you'd like for me to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevin, the tests I really need done are for someone with a STK525 to download MyUSB from my site, and run the demos on the board. I especially want to know if the Mass Storage demo works correctly, as well as the Mass Storage Host demo.

Try using the former, and see if you can write/read from the drive in Windows. Then try the latter, and see if you can read several different flash disks with no freezing or crashes.

Thanks!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very fine, Dean -- glad to do that minor bit of assistance (and even more glad to be using your library!) I'll report with my findings.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, for your mass storage tests, I imagine they'd be easier to perform using a ATEVK525 in addition to the STK525. As I only have the STK525 and not the ATEVK525, do you have recommendations on a test for your mass storage driver? The STK525 comes with a soldered, serial data flash, but not a SD/MMC connector. However, I could look to connecting a SD/MMC holder to jumpers and then to the STK525.

Edit: Neither mouser nor digikey have a ATEVK525 part on their site, so I guess I'm not alone in not having a ATEVK525!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The mass storage device demo uses the serial dataflash as the storage medium, so it should work with the STK525. The mass storage host expects a standard USB flash disk to be connected to the USB port of the STK525, so it can be read.

Haven't looked into making a card reader out of it yet -- to many things to do.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the additional information, Dean, very helpful, indeed. I'll let you know how it goes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Kevin, the tests I really need done are for someone with a STK525 to download MyUSB from my site, and run the demos on the board.
Dean, I ported the MassStorage demo for the STK525 by
- Creating a new driver directory STK525 alongside of USBKEY
- Porting the driver headers to (near) equivalents of the STK525. The biggest change is changing Bicolour.h to Monocolour.h
- Adding a PLATFORM_STK525 definition to MassStorage's makefile
- Selecting the appropriate drivers if PLATFORM_STK525 is defined

With that, I'm able to compile and load the MassStorage demo. But, perhaps I'm doing this all wrong. Your initial post asked a volunteer to program a hex file you'd supply and then a later post you stated to download and compile the MyUSB project. Do you have a particular .hex file you want me to test?

At this point, Windows find a disk, but the size is wrong. I believe the difference is that the STK525 uses only a single 32Mb flash versus the two 64Mb flash of the USBKEY and that I don't have the addresing correctly ported to the STK525.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha, I wasn't aware of the hardware differences - I thought that the STK525 had identical hardware, except the bicolour channels were split into four separate LEDs (but would still work with the existing driver).

Once I get my laptop back and working, I'll create a STK525 port. I might have to shuffle around the directories a bit, create a new STK525 directory, and move both that and the USBKEY inside a new directory housing drivers common to both boards.

Fixing the dataflash issue should be fairly simple, with a few driver and code changes.

When I have the library port done, I'll send you both the code and the HEX file for testing.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're right most of the hardware is similar, but there is enough difference that porting is necessary. I imagine you've seen this, but here's the PDF for the STK525 hardware: http://www.atmel.com/dyn/resourc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, while you consider how to integrate another set of drivers in your package and making a generic interface, you might also want to consider supporting STK526 hardware as well. I read in a another thread ( https://www.avrfreaks.net/index.p... ) about your (and avr-libc's) work on supporting AT90USB162.

If you decide to add hardware support for the STK526, I'm willing to purchase one that I can use for testing of your port.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you might also want to consider supporting STK526 hardware as well

That's a good idea - I didn't know the STK526 existed until I typoed in my Google search for the STK525. Since MyUSB is theoretically compatible with the AT90USBXX2 now, it would be a good idea to support the STK526.

My biggest issue is keeping the demos as simple as possible. I need to decide whether I want to make the demos generic and have the correct target board selected by the makefile, or whether I want to just stick with supporting the USBKEY in the demos, but provide alternate drivers for the STK52X.

I think one of MyUSB's greatest strengths is the simplicity of the applications which use it, as shown by the demos. I don't want to scare people off when they look at the sample applications, as the code isn't hard at all.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the tradeoff between simplicity and broad support is a recurrent theme. Simple demos are nice -- however, to the degree the demos provide a testing mechanism for your library on multiple platforms -- it would be nice to have a standardized tests so if people report issues on a platform, you'd have a known code base.

In terms of supporting the demos on different platforms, I have a few observations.

1) I created a Monocolour driver for the STK525 which hasn't hard -- but you use the Bicolour driver quite a bit in your demos. There are a lot of #if/#else in the demo file for the different LED drivers. This is unreasonable. Perhaps the most straightforward and simplest approach is to say on the STK525 and STK526 that each group of two leds makes a virtual bicolour pair. That prevents demo code with having to deal with 4 mono leds vs. 2 bicolour leds.

2) Rather than #if/#else in the demo .h files (based on platform), they can load a dispatching .h file which will include the appropriate driver for their platform.

3) You may want to considering using autoconf/automake (available in Windows with the cygwin (and I think mingw) distribution) to create the makefiles for the demos. Then, a user can just perform something like
./configure --platform=usbkey --f-cpu=16000000
and have the makefiles automatically generated for them.

However, configure isn't a commonly used tool on windows and editing a makefile is not difficult -- so I think this point is not very essential.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevin, are you able to do an updated test? I've uploaded the latest internal version to:

http://www.fourwalledcubicle.com/files/temp/MyUSB%20INTERNAL%2027FEB.zip

It should be compatible with the STK525, by changing the "BOARD = " line in the makefile. It should show up as the correct capacity.

I've renamed the previous directory holding USBXXX6 and USBXXX7 specific drivers to just "AT90USBXXX", as they should work on the USBXXX2 also. I've also renamed the USBKEY directory to "Board", which includes board-specific drivers automatically via dispatch headers according to the platform defined in the makefile.

Let me know how it goes.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, Dean -- sounds good. How'd you do all that with your computer sent for repair?

I'll be able to test tomorrow and will report back.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got impatient and extracted the work directory from my backups, and re-downloaded WinAVR for one of the family PCs. Not perfect, but enough to at least work on it a tiny bit.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
I got impatient and ...
I think most of us here can relate to that :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

True! Two days was all it took to go stir crazy and download WinAVR for the family computer. I can't totally vouch for the USBXXX2 AVRs working with the chip drivers, but the STK525 with its USBXXX6 or USBXXX7 chip should work fine with the new board target value set correctly.

The demos actually have zero code changes to deal with the different platforms, except for the Mass Stoage code which needs two preprocessor checks to determine how many dataflash ICs are mounted on the selected board. I'm quite happy with that -- it means the demos stay simple, and can be compiled for any platform without any invasive changes.

I went with keeping the bicolour driver as a common driver - for the STK525, just assume the LEDs form virtual bicolour pairs as you suggested, as that seemed the easiest option.

Now, I need to do the STK526, but I can't seem to download the hardware user guide to get at the schematics. I get timeouts after the first 50KB or so -- anyone willing to download it for me and attach it here/to an email? I can download anything else just fine (albeit slowly), just not that one file.

MyUSB 1.3.0 (or 2.0.0, since there are a lot of big changes) will support all the boards (USBKEY, STK525, STK526) as well as all the current USB AVR models (AT90USB1287, AT90USB1286, AT90USB647, AT90USB646, AT90USB162, AT90USB82).

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's nice how easily the generalization of platforms went. I put a mirrow of the STK526 HW Guide at http://www.b9.com/elect/avr/stk5...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Changes complete. The new internal version should be compatible with all USB AVRs, and all Atmel USB boards.

http://www.fourwalledcubicle.com/files/temp/MyUSB%20INTERNAL%2028FEB.zip

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Woo hoo, Dean! That's rapid work. I'll likely have a STK526 by mid-March for testing. I'll get to the STK525 test this weekend.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great, let me know if I've missed anything.

The TODO list is getting smaller - still need to debug the new Bootloader's memory write code, and finish off the Still Image demo so that it actually does something useful.

Any more feature requests?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, one thing I noticed doing a code review and test compilation on Linux is that parenthesis need to be escaped in the command lines that the makefile will generate. Here's one sample diff to have compilation work on linux:

kevin@hare:~/src/dl/myusb/Demos> diff -iuw MassStorage/makefile.~1~  MassStorage/makefile
--- MassStorage/makefile.~1~	2008-02-27 16:08:16.000000000 -0700
+++ MassStorage/makefile	2008-02-27 21:40:23.000000000 -0700
@@ -142,7 +142,7 @@
 
 # Place -D or -U options here for C sources
 CDEFS  = -DF_CPU=$(F_CPU)UL -DBOARD=BOARD_$(BOARD)
-CDEFS += -DUSB_DEVICE_ONLY -DUSE_STATIC_OPTIONS=(USB_DEV_OPT_HIGHSPEED | USB_OPT_REG_ENABLED)
+CDEFS += -DUSB_DEVICE_ONLY -DUSE_STATIC_OPTIONS="(USB_DEV_OPT_HIGHSPEED | USB_OPT_REG_ENABLED)"
 
 
 # Place -D or -U options here for ASM sources

So far your changes look good. Next, to test on hardware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Dean, one thing I noticed doing a code review and test compilation on Linux is that parenthesis need to be escaped in the command lines that the makefile will generate.

Fixed - I've added the escapes to all the demos. Thanks for catching that - good to know it compiles under Linux too.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As always, Dean -- speedy work!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CHirst has identified a problem using the STK525 and the Mass Storage Demo app. I've managed to fix a few of the problems, but it still fails to format. It requires more investigation -- thankfully I can replicate the problem by changing the number of Dataflash ICs in the USBKEY dataflash header to 1.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad that you a platform where you can replicate the problem. I'll hold off on stk525 testing until the next work release. Thanks for the notice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No worries - I'll let you know. I'm building up my TODO list again:

Quote:
* Finish bootloader (memory program code)
* Finish Still Image demo (add some practical function)
* Fix port to USBXXX2 - some registers have changed between AVRs
* Fix Mass Storage Demo for STK525/STK526
* Fix USBtoSerial INI file - not accepted by host

Let me know if you have anything else you want added to the next release.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Last Edited: Sat. Mar 1, 2008 - 04:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Let me know if you have anything else you want added to the next release.
That's very kind of you to ask. But, everything that I thought of I felt guilty about -- as in, if I want that feature I should do it myself rather than asking someone else. But, I'll let you know if I get over that guilt or think of something over my head that would also benefit others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

That's very kind of you to ask. But, everything that I thought of I felt guilty about -- as in, if I want that feature I should do it myself rather than asking someone else.

Nope please do ask. I'd rather the functionality was added to the core library so eveyone could benefit, rather than tacked on by each user. Don't be afraid to ask for things that you'd like to see in it -- worst I can say is do it yourself!

Finished the USBXXX2 port. I still need to have a look at those INI files, as I can't fathom why they're failing -- the only difference is in the PID value which should be correct.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got it! Found the Mass Storage Demo problem. The new internal code (which should work on all USB AVRs, and all boards) can be downloaded at:

http://fourwalledcubicle.com/fil...

And shouldn't have any problems.

The problem was due to the Dataflash selection code. On the USBKEY, there are two Dataflash ICs. To speed things up, when writing or reading to it, alternate Dataflash chips are selected -- that means that while the first dataflash chip is executing the main memory write command, the second Dataflash can be recieving the next block of data. The mechanism for switching between the two is given by the Dataflash_SelectChipFromPage() routine.

Now, when only one Dataflash chip is present, the routine always selects the first Dataflash IC. This is a problem as the code relied on the fact that another Dataflash IC was selected, as that would ensure that the dataflash is ready for the next operation as the /CS line is guaranteed to change. However, when only one Dataflash chip is mounted, the routine doesn't do anything -- the Dataflash CS line isn't toggled, thus any subsequent commands would still be attached to the last memory write/read command.

Fixing the problem just required the Dataflash_SelectChipFromPage() routine to explicitly toggle the /CS line if only one Dataflash is present.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent work, Dean. I'll test in the STK525 and let you know how it goes. As for my feature request, it would be a more fleshed out keyboard host application which features like caps lock, sending function keys and modified function keys as codes > 127, numeric keypad, direct alt decimal entry.

I actually wrote code to do all that for PS/2 keyboards, but as PS/2 is/has become legacy, I'm thinking a simple USB keyboard to RS232 output would be a nice module for integration into a larger project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok Kevin, added to the to-do list. That will be low-priority (but will be done, keep those suggestions comming!), yielding to the Bootloader and Still Image Host demos, as I want to get those *working* before enhancing other demos.

I want to get 1.3.0 out ASAP, so at the moment it's blocking on the bootloader only.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, sorry to report that initial testing of MassStorage on a STK525 is a no-go. I downloaded the WORK version just now, modified the Makefile to set BOARD to STK525 and it compiled fine without problems. Uploaded with FLIP 3.3. This time, as opposed to my initial STK525 port showing a flash size of 16MB, the volume shows up on Vista but is reported to be 0 bytes in size.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah bugger. At least I know the logic is now correct for a single dataflash.

I don't have access to the code right at this minute. Could you change the main routine so that it calls the Dataflash checking function (I think it's in VirtualMemory.c) on startup and gives an obvious indication of a dataflash error? That way I can narrow it down to something other than the dataflash driver for the STK525.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Ah bugger. At least I know the logic is now correct for a single dataflash.
You are not deducing that from my report, are you? Are you stating that based on your knowledge of the coding changes that you had made?
Quote:
I don't have access to the code right at this minute. Could you change the main routine so that it calls the Dataflash checking function (I think it's in VirtualMemory.c) on startup and gives an obvious indication of a dataflash error? That way I can narrow it down to something other than the dataflash driver for the STK525.
Sure, I can work on that tonight; I've got family plans already setup for the day.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You are not deducing that from my report, are you? Are you stating that based on your knowledge of the coding changes that you had made?

I can now set the USBKEY header's "Total Dataflashes" constant to 1 and have it enumerate as a 8MB flash disk, so single-dataflash works in the logic alone. The problem must be with the STK525 Dataflash header or something else I'm missing.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see, Dean, that makes sense. I took a look at the MassStorage demo code. There's no VirtualMemory.c file, but there as some VM functions in Demos/MassStorage/DataFlashManager.c But, I didn't see any "the Dataflash checking function". I'll work on taking another look later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops! You're right, I called it DataflashManager.c and the function I was thinking of was actually in SCSI.c anyway -- SCSI_Command_Send_Diagnostic().

In the main function, add the code:

	/* Test first Dataflash IC is present and responding to commands */
	Dataflash_SelectChip(DATAFLASH_CHIP1);
	Dataflash_SendByte(DF_CMD_READMANUFACTURERDEVICEINFO);
	ReturnByte = Dataflash_SendByte(0x00);
	Dataflash_DeselectChip();

	/* If returned data is invalid, fail the command */
	if (ReturnByte != DF_MANUFACTURER_ATMEL)
	{
		Bicolour_SetLeds(BICOLOUR_LED1_ORANGE | BICOLOUR_LED2_ORANGE);
		for(;;);
	}

After the Dataflash_Init(DATAFLASH_SPEED_FCPU_DIV_2); line, and run it. If you get all four LEDs stuck on, then there's a problem with the dataflash driver.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the code, Dean -- it compiles fine after declaring ReturnByte. I'll upload it when I get to my STK525 and report what happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
If you get all four LEDs stuck on, then there's a problem with the dataflash driver.
Dean, the firmware passes this test fine -- no stuck LEDs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bugger - looks like the dataflash command codes for the chip used on the STK525 differ slightly to the ones on the USBKEY, despite being of the same Dataflash family. Stand by.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the bad news -- thanks for investigating!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, try the attached. I'm able to use the USBKEY in single Dataflash mode, so it's not a problem with the selecting of a single dataflash anymore. The capacity is also reported correctly for a single dataflash (as it should - the capacity is read via a seperate SCSI command and not from the dataflash) but it seems if Windows determines the volume to be corrupt, it indicates a 0 byte capacity.

The new code uses dataflash command codes updated for the STK525's dataflash, and so should now read/write correctly.

- Dean :twisted:

Attachment(s): 

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean, firmware downloaded via FLIP. Same behavior as before: volume shows up quickly, selecting properties for the device takes about 20 seconds to show up, and when it does it shows a device size of 0 bytes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Infuriating. Unfortunately I'm stumped for the moment -- unless someone can get access to a STK525 and a JTAG (or I can get a loan of one myself) I can't think of many more avenues to pursue.

The long delay seems to indicate it's a command timing out or the like. I'll have to ponder it a little more.

Perhaps adding some serial logging to the void SCSI_DecodeSCSICommand(void) routine would be in order, so the commands from the host can be viewed? If you get a continuous stream of READS while its hanging for example, it might still indicate a corrupted data stream.

I can set the USBKEY's dataflash header to 1 dataflash, 512KB pages to match the STK525 and it all works fine. Perhaps it's your OS sending strange requests?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
unless someone can get access to a STK525 and a JTAG
I have a couple of JTAGICEMkII's that I can use for some testing.
Quote:

Perhaps adding some serial logging to the void SCSI_DecodeSCSICommand(void) routine would be in order, so the commands from the host can be viewed? If you get a continuous stream of READS while its hanging for example, it might still indicate a corrupted data stream.
Sounds like a good idea.
Quote:
Perhaps it's your OS sending strange requests?
Possibly, I'm testing on Windows Ultimate. But, I also have Linux and Mac OS X that I can test the firmware on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First try with one of the other OSes, but you did say that your original port was able to report a capacity, even if it didn't work.

Attached is the latest source, for debugging purposes.

- Dean :twisted:

Attachment(s): 

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Pages