i encountered the following strange situation:
i am coding some rr-net using code on PC and transfer it via codenet to c64. then I reset the c64 (reset button) AND switch RR in Flashmode then i start my code and it won't run properly, that is it seems that the rr-net is somehow blocked and won't recieve anything when i throw some frames on it...
as said the same code runs roperly if i save it to disk, turn on and off again the c64 load and run it... is codenet messing up the rr-net in some way that even a hard reset and a chip reset (which i do in the code) "survives"...?!

what address range are you transferring to?

Is using the clockport in Flashmode actually documented to be safe?

i transfer mostly to $c800-$cfff but i think i used other areas too... why are you asking??!

i tried in flash mode and not in flash mode. i often switch into flashmode while developing something to be sure that the TFR doesn't interfere in any way with my code...

I'm asking because you said it didn't work when transferring using CodeNet, but worked when loading from floppy. Does CodeNet support loading to the addresses you're using is the real question I think.
You could try transferring a known pattern to the addresses you're using instead of your binary and then examine the transferred data and/or save it to disk for examination. This should reveal if the stuff you transfer using CodeNet is actually what you expect.
Hurhrmm.. Graham has made weird errors before

..oh, and personally I have seen lots of transfer errors. If you do a check with known data, use a pattern that will reveal byteswapped data, e.g. the alphabet. If the data is byteswapped at some places, well.. then you're fucked - but I can explain that further if that's what you find.

oh no, the code is transfered correctly and executes properly in the first place, that's not the problem (yes, codenet uses the first two bytes as "load" address)
the transfered data isn't corrupted either - the problem is more that if i run the transmitted code which itself uses the rr-net, rr-net reception of frames seems to be blocked. Normally the code should recieve a frame from my pc and react upon - and it does this very well if started without having used codenet before, e.g. if loaded from disk - but after a transfer with codenet the reception of frames fails and nothing happens (well the rr-net actually recieves the frames since the green LED is flashing but something goes wrong "on its way to my code" if you know what i mean...)
i have a workaround now of simply not using codenet anymore for this purpose but my own tool netmon instead but i think this is strange anyway.

I noticed the same thing. (I think)

I get around it by pinging the c64 twice . I wrote a little batch file to do it before I try another xfer.

If I remember correctly this loading via CodeNet works with my code/rr-net. How does your init code look?

My init does the following:

1 - Reset NIC
1.1 - Wait for NIC to reset, verify this by reading back SelfST and checking for INITD bit. This verification doesn't work in Vice though!
2 - Detect NIC by reading ProductIDCode
3 - If NIC detected OK, setup NIC
3.1 - Set bits RxCTL_BroadcastA, RxCTL_IndividualA and RxCTL_RxOKA in register RxCTL (write #$0d05 to $0104)
3.2 - Set the MAC address
3.3 - Finally enable transmission and reception by setting bits LineCTL_SerTxON and LineCTL_SerRxON in register LineCTL (write #$00d3 to $0112)


I'll just confirm that it actually works when loading it via CodeNet and resetting, once I get home tonight.. just to be sure

oh, and are you writing the same MAC address to the NIC as CodeNet is using? - and if not, are you remembering to flush the relevant ARP caches on the connected systems? - This is only relevant if your CodeNet and you own code uses the same IP address of course.
- just checking

@bones: yes, pinging helps but it needs much more than two pings inmy case, if i issue pings ina n 0.2 sec interval it needs up to one minute until the rr-net is "free"...
@devia: i'll check my init against yours, maybe i missed something...

erhm.. doesn't linux do negative ARP caching?

I don't do a software reset of the 8900 and I've never had any problems with CodeNet, but I'm not using the same IP address either. Hence no ARP problems.

Just to follow up:

I just tested loading some ICMP code to my RR using CodeNet from TFR and then running the program (no reset) and it works perfectly (as in, I can ping my ICMP code) as long as I flush my arp cache in between the CodeNet load and my following ping test (my code uses a different MAC than CodeNet).

Well, I don't think it is at all necessary. I just think it's a good practice to re-initialize hardware that "might" have been used by something else prior to my use. As is the case in this situation.
In other words: It's good practice and it takes up very little space to do it.

Agreed.

ok, i solved the problem. it is that i use in fact another mac address and so the pc's arp cache contains still the mac-address set by TFR and of course these packets are rejected by the rr-net since it has another mac address now.
just delete the pc's arp-cache with

or what have you as ip-address... that's it. so, devia, you were perfectly right and tfr isn't to blame either
btw: isn't there a possibility to flush the whole cache or something shorter in linux?!