Matrix user forums

Strange thing is that when I put the card into the cardslot, the whole programmer is being reset.

I always had problems with the XTAL/RC switch on the programmer board since I bought it.
Could this be a problem? Most of the time it works, but this is a problem with the design and the choice of the switch?

	#if (MX_HW_SPI == 0)								//Software Mode

		char idx;
		for (idx = 0; idx < 8; idx++)
		{
			if (test_bit(shift, 7))
				set_bit(MX_CARD_PORT, MX_CARD_SDO);		// Set SDO bit
			else
				clear_bit(MX_CARD_PORT, MX_CARD_SDO);	// Clear SDO bit

			shift = shift << 1;

			set_bit(MX_CARD_PORT, MX_CARD_SCK);			// SCK Output 1

			delay_us(10);	//Added Delay ************************************

			if(test_bit(MX_CARD_PORT, MX_CARD_SDI))
				shift = shift | 0x01;
			else
				shift = shift & 0xFE;

 			delay_us(10);	//Added Delay ************************************

			clear_bit(MX_CARD_PORT, MX_CARD_SCK);		// SCK Output 0

			delay_us(10);	//Added Delay ************************************

		}
		return shift;

	#endif
	#if (MX_HW_SPI == 1)								//Hardware Mode

		#ifndef MX_SPI
			#ifdef _BOOSTC
				#pragma error "Chip does not have SPI capability"
			#endif
			#ifdef HI_TECH_C
				#error Chip does not have SPI capability
			#endif
		#endif

		sspbuf = shift;									//write the Char
		while ((sspstat & 0x01) == 0);					//wait until sspbuf is empty
		shift = sspbuf;									//receive the Char
		return shift;

	#endif

Benj wrote:Hello,

Hm sounds like there is something that is not quite working correctly.

Strange thing is that when I put the card into the cardslot, the whole programmer is being reset.

This is normal operation for the board.

I always had problems with the XTAL/RC switch on the programmer board since I bought it.
Could this be a problem? Most of the time it works, but this is a problem with the design and the choice of the switch?

If the program is running at all then the switch position is ok. We do use a fairly low cost switch on the EB006 but they are quite reliable and there are few comments or complaints about them related to the amount of EB006 programmers we sell. At the end of the day they are low cost to help save you money on the sale price.

I would assume that thuis is a card problem. One thing you could try is to adjust the timings of the SPI transactions just incase they are slightly out of tolerance for your card. Using the custom code feature edit the SPI_BYTE function.

Maybe try editing the code so that the following delays are added.

Code: Select all

	#if (MX_HW_SPI == 0)								//Software Mode

		char idx;
		for (idx = 0; idx < 8; idx++)
		{
			if (test_bit(shift, 7))
				set_bit(MX_CARD_PORT, MX_CARD_SDO);		// Set SDO bit
			else
				clear_bit(MX_CARD_PORT, MX_CARD_SDO);	// Clear SDO bit

			shift = shift << 1;

			set_bit(MX_CARD_PORT, MX_CARD_SCK);			// SCK Output 1

			delay_us(10);	//Added Delay ************************************

			if(test_bit(MX_CARD_PORT, MX_CARD_SDI))
				shift = shift | 0x01;
			else
				shift = shift & 0xFE;

 			delay_us(10);	//Added Delay ************************************

			clear_bit(MX_CARD_PORT, MX_CARD_SCK);		// SCK Output 0

			delay_us(10);	//Added Delay ************************************

		}
		return shift;

	#endif
	#if (MX_HW_SPI == 1)								//Hardware Mode

		#ifndef MX_SPI
			#ifdef _BOOSTC
				#pragma error "Chip does not have SPI capability"
			#endif
			#ifdef HI_TECH_C
				#error Chip does not have SPI capability
			#endif
		#endif

		sspbuf = shift;									//write the Char
		while ((sspstat & 0x01) == 0);					//wait until sspbuf is empty
		shift = sspbuf;									//receive the Char
		return shift;

	#endif

If this works more reliably then you can start to reduce the delays until you have an optimal setup for your card.

Hopefully when you receive your new card it will work with the code as is.

Let me know how you get on.